Bug 624149 - RFE: Better compatibility with shutdown traditional semantics
RFE: Better compatibility with shutdown traditional semantics
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2010-08-13 16:18 EDT by Matthew Miller
Modified: 2015-10-21 04:42 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-21 04:42:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2010-08-13 16:18:33 EDT
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.
Comment 1 Matthew Miller 2010-08-15 09:57:11 EDT
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).
Comment 2 Lennart Poettering 2010-08-16 10:03:05 EDT
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.
Comment 3 Lennart Poettering 2010-08-16 10:04:23 EDT
s/submits/supports/
Comment 4 Matthew Miller 2010-08-16 10:15:20 EDT
(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.
Comment 5 Matthew Miller 2010-08-16 10:29:32 EDT
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)
Comment 6 Matthew Miller 2010-08-16 10:45:21 EDT
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". :)
Comment 7 Lennart Poettering 2010-08-16 11:20:58 EDT
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/.
Comment 8 Matthew Miller 2010-08-16 11:53:37 EDT
(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.
Comment 9 Matthew Miller 2010-08-16 12:11:54 EDT
> Yeah, I'll file a bug. I believe ssh implements it directly too, not just with
> pam_nologin.

Bug #624489
Comment 10 Lennart Poettering 2010-08-16 12:12:53 EDT
(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.
Comment 11 Matthew Miller 2010-08-16 12:17:39 EDT
> 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.
Comment 12 Lennart Poettering 2010-08-16 13:28:40 EDT
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...
Comment 13 Matthew Miller 2010-08-16 13:36:29 EDT
(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. :)
Comment 14 Lennart Poettering 2010-08-17 12:23:35 EDT
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.
Comment 15 Matthew Miller 2010-08-17 12:31:10 EDT
(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.
Comment 16 Lennart Poettering 2010-08-17 13:07:38 EDT
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.
Comment 17 Bill Nottingham 2010-08-17 13:15:59 EDT
fastboot has been a supported boot option since 2000, forcefsck since 2003. (in RH/Fedora, at least.)
Comment 18 Matthew Miller 2010-08-25 11:51:10 EDT
I'm going to reopen this and then mark it as NEEDINFO from me, pending testing.
Comment 19 Matthew Miller 2010-08-26 14:33:17 EDT
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.
Comment 20 Andrew Clayton 2010-09-07 17:09:47 EDT
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.
Comment 21 Aissen 2011-05-25 18:06:43 EDT
Just installed a fresh F15;
shutdown -h 5m
isn't supported. It should also work with:
shutdown -h 5h
Comment 22 Michal Schmidt 2011-07-02 18:30:26 EDT
(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.
Comment 23 Aissen 2011-07-03 16:44:47 EDT
(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()
Comment 24 Michal Schmidt 2011-07-04 17:27:41 EDT
Some of the improvements are included in:
https://admin.fedoraproject.org/updates/systemd-26-6.fc15
Comment 25 Fedora Admin XMLRPC Client 2011-10-20 12:26:28 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 26 Jóhann B. Guðmundsson 2012-02-27 05:44:09 EST
Ping what's the current status of this?
Comment 27 Michal Sekletar 2012-08-27 10:38:59 EDT
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
Comment 28 Giuseppe Ragusa 2012-10-03 12:37:46 EDT
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
Comment 29 Adam Williamson 2012-10-05 03:27:13 EDT
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.
Comment 30 Matthew Miller 2012-10-05 11:31:15 EDT
(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.
Comment 31 Bill Nottingham 2012-10-05 11:39:03 EDT
I believe the current default polkit policy is:

- remote: always password
- local: password only if others logged in
Comment 32 Giuseppe Ragusa 2012-10-05 12:29:03 EDT
(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).
Comment 33 Matthew Miller 2012-10-05 12:58:49 EDT
> 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"
Comment 34 Giuseppe Ragusa 2012-10-05 13:17:34 EDT
(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?
Comment 35 Harald Hoyer 2013-04-10 06:14:46 EDT
Is this still an issue?
Comment 36 Andrew Clayton 2013-04-10 08:49:38 EDT
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.
Comment 37 Giuseppe Ragusa 2014-03-26 15:12:41 EDT
(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.
Comment 38 Jan Synacek 2015-10-21 04:42:04 EDT
The concern from comment 36 filed upstream as https://github.com/systemd/systemd/issues/1631. Everything else is fixed.

Note You need to log in before you can comment on or make changes to this bug.