Description of problem: I ran "shutdown -h 06:00 Emergency building power maintenance ", expecting to power down my system at 6am tomorrow for the (noted) power emergency. But instead, I got the message "First argument '06:00' isn't 'now'. Ignoring." and my system powered down immediately! From the systemd man page: The first argument should be the string now which however is ignored by this implementation. Optionally, this may be followed by a wall message to be sent to all logged-in users before going down. This is a dangerous and surprising change. The primary use of the shutdown command in a multi-user environment is to shut down the system _after a warning period_. Not only does the new systemd not handle this case, but it degrades very, very badly. The "now" keyword is not decorative -- it's a handy shortcut for a common special case. Version-Release number of selected component (if applicable): systemd-7-1.fc14.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Run shutdown with a timespec 2. Surprise! Actual results: System shuts down instantly. Expected results: System shuts down in manner compliant with traditional shutdown command: The time argument can have different formats. First, it can be an absolute time in the format hh:mm, in which hh is the hour (1 or 2 dig- its) and mm is the minute of the hour (in two digits). Second, it can be in the format +m, in which m is the number of minutes to wait. The word now is an alias for +0. If the time argument is not given, the command should exit with an error (as the traditional command does). In no case should shutting the system down be the response to a misunderstood syntax. Additional info: The /etc/nologin functionality should be implemented as well. If shutdown is called with a delay, it creates the advisory file /etc/nologin which causes programs such as login(1) to not allow new user logins. Shutdown removes this file if it is stopped before it can signal init (i.e. it is cancelled or something goes wrong). It also removes it before calling init to change the runlevel. Additionally, -c should cancel a running shutdown. It may be advisable to implement complete functionality as well, like the -f command to force a filesystem check. However, the lack of these features, and the consequences if that lack is not handled gracefully, is not as great as with the time argument.
The shutdown command provided with upstart also correctly implements a grace period, and the -c cancel command. It doesn't implement the filesystem check force flag or /etc/shutdown.allow. Also, note that the "reboot", "poweroff", and "halt" commands from the usermode package are appropriate to use when one wants the "instant action" behavior. On Monday, I'll take a look at the original code and provide a spec for the (undocumented?) behavior regarding at what times repeat shutdown-alerts are sent and when the /etc/nologin file is created (it's not immediate when the shutdown is scheduled for far in the future).
systemd git now submits delayed shutdown in the /sbin/shutdown command, as well as the -f, -F and -c switches. To be frank I find the samantics of these commands more than questionnable, but well, I guess for compatbility we should keep this behaviour around.
s/submits/supports/
(In reply to comment #2) > systemd git now submits delayed shutdown in the /sbin/shutdown command, as well > as the -f, -F and -c switches. Thanks! > To be frank I find the samantics of these commands more than questionnable, but > well, I guess for compatbility we should keep this behaviour around. There's legacy for ya. For what it's worth (not much, I guess, but for the record) this is the BSD style shutdown command. The Solaris version works slightly differently -- shuts down with a 60 second delay by default, which you can change with a "-g" flag. The FreeBSD man page lays out the behavior for warning messages and the nologin flag (here /var/run/nologin -- for whatever reason, Linux uses /etc/nologin still...) more explicitly: At intervals, becoming more frequent as apocalypse approaches and start- ing at ten hours before shutdown, warning messages are displayed on the terminals of all users logged in. Five minutes before shutdown, or imme- diately if shutdown is in less than 5 minutes, logins are disabled by creating /var/run/nologin and copying the warning message there. If this file exists when a user attempts to log in, login(1) prints its contents and exits. The file is removed just before shutdown exits. Give me a few minutes and I'll look at what you've got and at the legacy Linux shutdown command to verify that everything works similarly.
From the old source code: - /etc/nologin is created with 5 minutes to go. - warning messages are: -- immediately when command is run if shutdown time is in less than 15 minutes -- every 1 minute with less than 10 minutes to go -- every 15 minutes with less than 60 minutes to go -- every 30 minutes with less than 180 minutes (3 hours) to go -- every 60 minutes if more than that to go Low-priority future feature enhancements might be: - a flag to change the time at which /etc/nologin is created - migrating to the more-sensible /var/run/nologin (including updating sshd and whatever else)
Looked at your new code. Looks good, but I feel strongly that the default behavior with no timespec *can't* be to shut down immediately. That violates the "principle of least surprise", and could turn typos into serious problems. How about making it default to 60 seconds or 5 minutes in that case? That gives the unfortunate sysadmin a chance to recover from the mistake. Also, I see where you're reading arg_wall, but I don't see anything actually happening with it. Am I missing something there? Thanks! Oh, and at one point in shutdownd.c, you have "invaliud" instead of "invalid". :)
I have now changed the implied default to "+1" instead of "now", i.e. a 60s delay. That should give people enough time to issue "shutdown -c" if they want to correct an accidental shutdown request. arg_wall is written to the ttys in warn_wall() which is called from start_with_fallback() which is called from halt_main(). The "invaliud" is now fixed, too. /etc/nologin should probably indeed mvoe to /var/run/nologin, but that would have to be discussed with the maintainers of pam_nologin, first. Could you file a bug? If they'd look for both files then we'd have both compat with current systems and I could move what I write to /var/run/.
(In reply to comment #7) > I have now changed the implied default to "+1" instead of "now", i.e. a 60s > delay. That should give people enough time to issue "shutdown -c" if they want > to correct an accidental shutdown request. Cool, thanks. I'm a little worried about the "Failed to talk to shutdownd, proceeding with immediate shutdown" behavior -- it seems like that might bite someone at some point. > arg_wall is written to the ttys in warn_wall() which is called from > start_with_fallback() which is called from halt_main(). As I understand it, this is just a one-time message, not the increasingly-frequent announcement. That's important, as a reminder to people who ignored or missed the first one, or for people who logged in since the initial message. > /etc/nologin should probably indeed mvoe to /var/run/nologin, but that would > have to be discussed with the maintainers of pam_nologin, first. Could you file > a bug? If they'd look for both files then we'd have both compat with current > systems and I could move what I write to /var/run/. Yeah, I'll file a bug. I believe ssh implements it directly too, not just with pam_nologin.
> Yeah, I'll file a bug. I believe ssh implements it directly too, not just with > pam_nologin. Bug #624489
(In reply to comment #8) > (In reply to comment #7) > > I have now changed the implied default to "+1" instead of "now", i.e. a 60s > > delay. That should give people enough time to issue "shutdown -c" if they want > > to correct an accidental shutdown request. > > Cool, thanks. > > I'm a little worried about the "Failed to talk to shutdownd, proceeding with > immediate shutdown" behavior -- it seems like that might bite someone at some > point. Well, if that happens then things already went very wrong. Generally I think it we should make sure that if the user requested a shutdown we actually do shutdown, simply to avoid that hardware overheating or so, which might be the case when the user asks for a shutdown. It's similar to suspending: even if some things fail during suspend the suspend *must* take place, to avoid overheating, for example when the user closed his laptop. Hence I think it is smart if things are borked we shutdown immediately. That's said this should normally not happen. Things must already be very broken when we cannot talk to shutdown. > > arg_wall is written to the ttys in warn_wall() which is called from > > start_with_fallback() which is called from halt_main(). > > As I understand it, this is just a one-time message, not the > increasingly-frequent announcement. That's important, as a reminder to people > who ignored or missed the first one, or for people who logged in since the > initial message. Yupp, we currently don't do this wall message stuff following the scheme you pointed out. Which is what I am working on as we speak (or type... ;-)). Should be fixed soon.
> Hence I think it is smart if things are borked we shutdown immediately. That's > said this should normally not happen. Things must already be very broken when > we cannot talk to shutdown. That sounds reasonable. (Good to note clearly in the docs somewhere.) > Yupp, we currently don't do this wall message stuff following the scheme you > pointed out. Which is what I am working on as we speak (or type... ;-)). Should > be fixed soon. Cool. Again, I appreciate your attention to this. It'll help avoid a lot of pain from sysadmins (and documentation writers, for that matter) when this stuff goes into serious production use.
Now fixed upstream. I'll upload a new version of systemd soon (v8). Would be awesome if you could then verify that this works as intended as testing this properly is kinda time consuming, given that it basically means scheduling shutdowns for times that might be minutes or even hours away...
(In reply to comment #12) > Now fixed upstream. I'll upload a new version of systemd soon (v8). Would be > awesome if you could then verify that this works as intended as testing this > properly is kinda time consuming, given that it basically means scheduling > shutdowns for times that might be minutes or even hours away... Yeah, I'll be happy to. I've got a test system which can be devoted to shutdown tests for a while. :)
After some discussion with other folks we came to the conclusion that /forcefsck and /fastboot are evil and should be deprecated. And given that Upstart already did the deprecation work we shouldn't undeprecate this. The appropriate replacement is probably to introduce a kernel command line argument, which allows to control this at boot time, instead of shutdown time.
(In reply to comment #14) > After some discussion with other folks we came to the conclusion that > /forcefsck and /fastboot are evil and should be deprecated. And given that > Upstart already did the deprecation work we shouldn't undeprecate this. > > The appropriate replacement is probably to introduce a kernel command line > argument, which allows to control this at boot time, instead of shutdown time. Works for me. I've used the force fsck before, but only rarely -- and there's other ways to accomplish it in those rare cases. The delayed shutdown is the important part.
well, we'd probably support the two files for longer, but only check for them, never write them. The problem with writing them is that this requires a r/o root, which is something we shouldn't really rely on.
fastboot has been a supported boot option since 2000, forcefsck since 2003. (in RH/Fedora, at least.)
I'm going to reopen this and then mark it as NEEDINFO from me, pending testing.
Okay, so: basic timed shutdown seems to work, however the notifications aren't all there yet: 1) If a warning message is provided, this should be in addition to the standard line saying what is going to happen and when (reboot, whatever). 2) That broadcast message should be repeated immediately before shutdown. 3) Shutdown -c needs to respond with some sort of output like "shutdown canceled" 4) Traditionally, if you try to schedule a shutdown while shutdown is already running, that fails with a message "shutdown is already running". It's probably right to just follow that, although I can see an argument for letting whatever is scheduled for a closer time win.
Here's another one. shutdown -k actually powers off the system after a minute, when it should in fact just say it is, without actually doing it. From shutdown(8) on F12 -k Only send out the warning messages and disable logins, do not actually bring the system down.
Just installed a fresh F15; shutdown -h 5m isn't supported. It should also work with: shutdown -h 5h
(In reply to comment #19) > 1) If a warning message is provided, this should be in addition to the standard > line saying what is going to happen and when (reboot, whatever). Fixed upstream: http://cgit.freedesktop.org/systemd/commit/?id=30923233b34e23ed1b3ffa7317f6219f695fec2f (In reply to comment #20) > shutdown -k actually powers off the system after a minute, when it should in > fact just say it is, without actually doing it. Fixed upstream: http://cgit.freedesktop.org/systemd/commit/?id=52c002150a34c07a59369ee952bcd3a1f8f316ca (In reply to comment #21) > Just installed a fresh F15; > shutdown -h 5m > isn't supported. It should also work with: > shutdown -h 5h Was this ever supported? Neither SysVinit in RHEL 5 nor upstart in Fedora 14 can parse these.
(In reply to comment #22) > (In reply to comment #21) > > Just installed a fresh F15; > > shutdown -h 5m > > isn't supported. It should also work with: > > shutdown -h 5h > > Was this ever supported? Neither SysVinit in RHEL 5 nor upstart in Fedora 14 > can parse these. You're right, I checked in F14 and it wasn't supported. I thought it was in Debian, but checked and it isn't, either. I don't know where this idea came from. Now, this could be added in systemd, since there's already the infrastructure in src/util.c function parse_usec()
Some of the improvements are included in: https://admin.fedoraproject.org/updates/systemd-26-6.fc15
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Ping what's the current status of this?
I've introduced a change here, now it is possible to specify broadcast message when cancelling scheduled shutdown. Please see [1]. I don't know what else should be done here to make shutdown behavior more compatible with prior init systems. Please feel free to ask for more options which makes sense and were supported before. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=dfcc5c33f42554a5293e68e7093da2403e363997
As noted in comment #1 SysVinit used to support /etc/shutdown.allow to limit access to Ctrl-Alt-Del (even if in an awkward manner: simple check for anyone of listed users logged in on any local console): Upstart (at least in RHEL6) does not support it anymore by default (maybe leaves it to hacking the ctrl-alt-del snippet...), so systemd could revive it but maybe in a more intelligent manner. If I can unleash my sysadmin fantasy, maybe a simple list of users could behave as before, while user names prepended with a (colon separated) keyword could achieve something more fancy, along the lines of: active:root idle:johndoe tty2:guest
giuseppe: there's already a degree of PolicyKit interaction in shutdown/reboot operations in recent Fedora, especially in f18; I've been asked to enter a password to allow shutdown when simply running 'reboot' from a console. So it rather sounds like you could probably achieve that already with a custom PolicyKit policy, though I haven't poked at the details yet.
(In reply to comment #29) > giuseppe: there's already a degree of PolicyKit interaction in > shutdown/reboot operations in recent Fedora, especially in f18; I've been > asked to enter a password to allow shutdown when simply running 'reboot' > from a console. So it rather sounds like you could probably achieve that > already with a custom PolicyKit policy, though I haven't poked at the > details yet. In days of yore, reboot and poweroff used consolehelper, with a policy where users logged into the machine locally didn't need a password but remote users did.
I believe the current default polkit policy is: - remote: always password - local: password only if others logged in
(In reply to comment #31) > I believe the current default polkit policy is: > > - remote: always password > - local: password only if others logged in I understand the reference to PolicyKit (even if I'm not too familiar with it yet), but does it cover the (local console, for any reasonable definition of it...) Ctrl-Alt-Del behaviour in it's default configuration, or is it even possible to write policy to intercept/manage it? I thought that it was a sort of kernel-bound SAK (if nothing like an X server grabs the console input device).
> I thought that it was a sort of kernel-bound SAK (if nothing like an X > server grabs the console input device). init handles it. In our case, systemd. Check `man systemd.special` ctrl-alt-del.target systemd starts this target whenever Control+Alt+Del is pressed on the console. Usually this should be aliased (symlinked) to reboot.target. (Which it is, by default.) That, in turn, ultimately does "/usr/bin/systemctl --force reboot"
(In reply to comment #33) > > I thought that it was a sort of kernel-bound SAK (if nothing like an X > > server grabs the console input device). > > init handles it. In our case, systemd. Check `man systemd.special` > > ctrl-alt-del.target > systemd starts this target whenever Control+Alt+Del is pressed on > the console. Usually this should be aliased (symlinked) to > reboot.target. > > (Which it is, by default.) > > That, in turn, ultimately does "/usr/bin/systemctl --force reboot" So this brings us back to comment #28 Is it reasonable to ask for a more elaborate default for ctrl-alt-del.target (reviving /etc/shutdown.allow support from SysVinit etc.) or should this be left to the sysadmin as a local customization?
Is this still an issue?
One small discrepancy still is something like # shutdown [-k] -r now "Some Message" In this case nothing at all is displayed. Whereas previously you'd get something like (on RHEL5) Broadcast message from root (pts/1) (Wed Apr 10 13:42:21 2013): Some Message The system is going down for reboot NOW! Which is useful if there are people logged in and you want them to know why they got disconnected. If you specify a time instead of now it works as expected.
(In reply to Harald Hoyer from comment #35) > Is this still an issue? In relation to comment #34 I checked RHEL7 beta and the RHEL5-style /etc/shutdown.allow functionality is not present by default (ctrl-alt-del.target still simply links to reboot.target) and would require local customization.
The concern from comment 36 filed upstream as https://github.com/systemd/systemd/issues/1631. Everything else is fixed.