Created attachment 1418057 [details]
proof of fsck
Description of problem:
Something just caused a force shutdown (systemctl poweroff --force), right at the end of the offline update.
This actually *isn't* supposed to cause an unclean unmount, however for whatever reason I noticed it because all my filesystems had to be checked on startup. See attached.
Version-Release number of selected component (if applicable):
How reproducible: don't know
1. Offline update, by ticking the update tickbox when I shut down in Gnome.
Force shutdown, plus unclean shutdown
Offline update should normally end with an orderly shutdown (or reboot). I don't think we can justify using a forced shutdown when we're updating a bunch of critical system files.
(And if there's some strange error condition that made it necessary, that should have been logged).
Notice the lack of "Reached target Unmount All Filesystems.", etc in the log.
Apr 06 09:46:01.908746 alan-laptop PackageKit: update-packages transaction /17001_edadbdbc from uid 0 finished with success after 112114ms
Apr 06 09:46:02.067544 alan-laptop pk-offline-update: shutting down
Apr 06 09:46:02.069017 alan-laptop pk-offline-update: sent mode to plymouth 'shutdown'
Apr 06 09:46:02.070544 alan-laptop pk-offline-update: sent msg to plymouth 'Shutting down after installing updates…'
Apr 06 09:46:02.072926 alan-laptop systemd: Shutting down.
Apr 06 09:46:03.579270 alan-laptop systemd-shutdown: Sending SIGTERM to remaining processes...
Apr 06 09:46:03.580224 alan-laptop bluetoothd: Terminating
Apr 06 09:46:03.580303 alan-laptop alsactl: alsactl daemon stopped
Apr 06 09:46:03.580586 alan-laptop bluetoothd: Disconnected from D-Bus. Exiting.
Apr 06 09:46:03.580996 alan-laptop bluetoothd: Stopping SDP server
Apr 06 09:46:03.581022 alan-laptop bluetoothd: Exit
Apr 06 09:46:03.581470 alan-laptop PackageKit: daemon quit
Apr 06 09:46:03.619684 alan-laptop systemd-journald: Journal stopped
Created attachment 1418058 [details]
journal showing offline update and forced shutdown
Checking historical logs, it looks like this has always been the behaviour, so is fully reproducible.
I only noticed it, because of the unknown system failure that caused an unclean unmount.
Note that one advantage of an orderly shutdown is that I would have had logs for the unmount of every FS other than /, and /var. I.e. if there was some mysterious reason that my /boot filesystem (/dev/sda6) was in use and could not be unmounted, I would have a failure logged at that unmount step.
Orderly shutdowns give you better logs, and they're more widely used i.e. better tested.
See also https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html
"After completion (regardless whether the update succeeded or failed) the machine must be rebooted, for example by calling systemctl reboot." i.e. not `systemctl reboot --force`.
I regret to inform you that this the wrong dbus call to achieve this aim :)
val = g_dbus_connection_call_sync (connection,
What you need to do is call the StartUnit method instead, passing "reboot.target" as the `unit`, and "replace-irreversibly" as the `mode`.
I don't think any extra error handling is necessary, you don't want to wait for the `job` that StartUnit returns so you can just ignore that. And I think the existing error handling looks ok; just return to systemd, and as the offline-updates doc says, the units are set up so that systemd will reboot anyway.
(I think this means a failure to *power off* the machine instead falls back to a reboot. Not a new thing, and I'm not worrying about it).
Note, although `man systemd.special` points to the Reboot method on "org.freedesktop.login1.Manager", I think systemd-logind is not currently started during offline updates. (system-update.target pulls in sysinit.target, but I think not basic.target, which is what normally pulls in systemd-logind). And systemd-logind is not bus-activated.
My instinct is to stick with talking to systemd directly.
Comment #c3 is accurate: 'systemctl reboot' results in a call to org.freedesktop.systemd1.Manager.StartUnit with replace-irreversibly (see start_unit() called from https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L3656), and 'systemctl reboot --force' results in a call to org.freedesktop.systemd1.Manager.Reboot.
org.freedesktop.systemd1.Manager.Reboot is unnecessarily harsh, and shutting down normally through StartUnit is much better.
> My instinct is to stick with talking to systemd directly.
Yes, this seems reasonable. Going through logind is mostly about providing access to reboot for non-root users, which does not apply in this case. It should be fine to talk directly to systemd.
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30 Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '27'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 27 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.