Bug 1564462

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,
					   "org.freedesktop.systemd1",
					   "/org/freedesktop/systemd1",
					   "org.freedesktop.systemd1.Manager",
					   "Reboot",
					   NULL,
					   NULL,
					   G_DBUS_CALL_FLAGS_NONE,
					   -1,
					   NULL,
					   &error);


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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

For the record, I confirm this bug is now fixed.

Git commit: https://github.com/hughsie/PackageKit/commit/7f7006a91359
Discussion: https://github.com/hughsie/PackageKit/pull/251