systemctl: do not shutdown immediately on scheduled shutdown #18010
Conversation
When, for whatever reason, a scheduled shutdown fails to be set, system will proceed with immediate shutdown without allowing the user to react. This is counterintuitive because when a scheduled shutdown is issued, it means the user wants to shutdown at a specified time in the future, not immediately. This patch prevents the immediate shutdown and informs the user that no action will be taken. Fixes: systemd#17575
|
Did you follow the discussion on the issue? Why not just do what our documentation says and install D-Bus? |
What if d-bus is installed, but for some reason, the daemon is broken (like segfault)? Then users schedule a shutdown, and end-up having the machine rebooting immediately, this seems not the proper approach. |
Uh. Seriously. If D-Bus doesn't work, then scheduled shutdowns are the least of your concerns.
Yeah, but your change is suboptimal too, hence no benefit. And in contrast I have to deal with the fallout from this patch, i.e. that next person will come and complain that they asked for a shutdown and it didn't happen. |
Well not really, I also think the current behaviour is the best compromise as well you can make in an highly unusual and abnormal situation. Shutdown means shutdown. Also, changing behaviour would be a compatibility breakage in the systemctl interface, since it's pretty much always been that way AFAIK. And we are not too keen on those - tend to make users quite upset for some reason :-) |
|
@poettering stopping D-Bus is just the easiest way to reproduce the issue, not the real issue here. |
Can I refer you to my comment on the issue @poettering explaining how this problem was causing us problems in a real-world deployment (nothing to do with not installing D-Bus)? |
|
Well, that's an isolated anecdotal incident. I am pretty sure that other people would have preferred if the machine rebooted at all, to get it back into an operational state at all. i.e. reboot is an effective form of recovery in a failed state, and hence we should do it, if people ask for it, as good as we can. Anyway, sure, I see you disagree with this, and that's fine. Thing is, to change behaviour like this I think we need a good reason to plus a clear understanding that the changed behaviour would be sufficiently better than the status quo ante. I don't see that here at all. Sure, there are scenarios where not rebooting is better than rebooting immediately, but I doubt it's the clearly dominant scenario. And if it's this vague I am pretty sure we shouldn't change behaviour on this. I hope this is a viewpoint one can understand, even if one might disagree with it. Hence closing. |
|
Would not a more reasonable compromise would be to make this a configurable behaviour? Even if it is an anecdotal incident, the fact remains it caused a dataloss event. With the config option set, systemd could happily reboot if you specified "now" but if you specified some time in the future it could refuse and suggest you use a stopwatch and do a reboot at the prescribed time. That way people who value the timing of the reboot set the option and get what they want, and people who value rebooting don't set the option and get an immediate reboot. |
|
Thanks for the patch @joalif |
Every option comes at a price. If we make something configurable we need a very strong reason. I really don't see that here. It's a niche case, and one that has a perfect fix: just install dbus. I have zero sympathies for the folks who go against our documented dependencies and don't install dbus and the are surprised if some stuff doesn't work as expected, and get fallback codepaths. There's a very simple option that makes the whole issue go away for the majority of the people reporting this issue: just install dbus, as per doc. If you do, things just work, you get no failure, and the exact behaviour you expect: a scheduled shutdown. If you hate dbus that much that you'd rather want failures all over the place than just installing one tiny package that just makes everything works, then i am not sure I can help you. sorry. |
|
Eh? What are you talking about? In the example given dbus was installed, it had just crashed, something that happens. Who said anything about hating dbus but you? Bit disingenuous? |
In the original issue #17575.
Of cource, 'not available' may include a situation that dbus is installed but not running or crashed. But it is not a problem here. We explicitly request that dbus exists. If it does not for any reason, users should 'fix' the situation, that is, install, start, or restart dbus. |
|
Whilst I do not think it is unreasonable for you to expect dbus to be installed, I am not sure it is reasonable for you to expect a system admin to have to separately check dbus is running every time they issue a timed shutdown command or risk a nasty surprise. I realise the timing of shutdowns may not be important to your own usecase, but I am suggesting there are enough people out there for whom a mistimed reboot is an SLA violation that it might be worth the price of a config option. Anyway that's it I'm done. |
|
@mp15 consider it a packaging bug then maybe. i.e. ask your distro to just add the right dep so that dbus is always there if systemd is... On Fedora for example: # dnf repoquery --requires systemd | grep dbus
dbus >= 1.9.18i.e. the systemd rpm pulls in dbus so that this all just works. I mean, this is usually what packaging systems are used for: make sure the right stuff is pulled in for things to work. |
|
As said, I'll apply this downstream in Debian (and by that all derivatives including Ubuntu), which is certainly half of the Linux ecosystem. We will then see if people really don't like this (new) default behaviour. |
They can't because the system will have forcefully rebooted by then :-) |
Thanks a lot, much appreciated! I strongly agree with you that most people wouldn't like their system to just reboot if they say "please reboot i 15 minutes" due to some dbus issue... |
When, for whatever reason, a scheduled shutdown fails to be set, system
will proceed with immediate shutdown without allowing the user to react.
This is counterintuitive because when a scheduled shutdown is issued,
it means the user wants to shutdown at a specified time in the future,
not immediately. This patch prevents the immediate shutdown and informs
the user that no action will be taken.
Fixes: #17575