I've now pushed a PR which should alleviate the reboot issue
*partially*. The complexity in fixing this arises from the differing
behaviours of implementations of the shutdown, poweroff, and reboot
commands; upstart's poweroff & reboot commands for example, immediately
return (briefly) permitting the caller to query their exit codes. In
contrast, systemd's don't return at all unless the poweroff or reboot
fails. None of the reboot or poweroff implementations provide a
scheduling facility like the /sbin/shutdown implementation
(unsurprisingly), but systemd's poweroff and reboot commands *do* work
even in the post-trusty upgrade environment (even though systemd's
shutdown command doesn't).
The quandry is as follows: we can reliably detect when the shutdown
command fails (it exits with an exit code and some error messages), and
when it succeeds ... sort of. We currently schedule the shutdown for 4
minutes time and if it hasn't died within 10 seconds we assume it's
going to work; this assumes that the implementation won't fail at the
end of the schedule but so far that seems a reliable assumption under
both upstart and systemd. We cannot *reliably* detect when the poweroff
or reboot commands either succeed or fail, but they do seem reliable in
practice even in aberrant environments like the post-trusty upgrade.
So, the method I've chosen is as follows: treat shutdown and restart
requests as we presently do (schedule /bin/shutdown for 4 minutes time,
monitor for 10 seconds). If it succeeds, nothing changes. If it fails,
report the failure with an extra message indicating we are going to
attempt to force the procedure, then run /sbin/poweroff or /sbin/reboot
as appropriate. The result is that in the post-trusty environment
(testing on containers and VMs) a reboot request does succeed, but is
still reported as failing (albeit with an extended message explaining
we're going to try and force it).
We *could* report it as succeeding, but frankly there's no guarantees so
it's a choice between giving the user bad news ("sorry your reboot
request failed ...") with a possible silver lining ("... but we're going
to try another way which *might* work, however we won't be able to
tell"), or giving the user good news ("your reboot request worked after
we forced it") and hoping we're not lying! The former sounds like the
more sensible approach to me, and hence is what is in the PR
(https://github.com/CanonicalLtd/landscape-client/pull/55).
** Changed in: landscape-client (Ubuntu)
Assignee: (unassigned) => Dave Jones (waveform)
** Changed in: landscape-client (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1670291
Title:
Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot
Status in landscape-client package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
Incomplete
Status in landscape-client source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Incomplete
Bug description:
Used Landscape (Paid Canonical Subscription) to upgrade one of my
machines.
Landscape only shows "In Progress" for more than 8 hours now and asked
for a reboot of the machine in a second alert.
In the reboot attempt I get the message:
=========================
Failed to set wall message, ignoring: Method "SetWallMessage" with signature
"sb" on interface "org.freedesktop.login1.Manager" doesn't exist
Failed to call ScheduleShutdown in logind, proceeding with immediate
shutdown: Method "ScheduleShutdown" with signature "st" on interface
"org.freedesktop.login1.Manager" doesn't exist
=========================
Steps to reproduce:
* Fully updated 14.04.5 machine
* Open Landscape
* Choose the machine
* Choose Packages
* This computer can be upgraded to a newer release
* Apply
* Wait 2 hours
* Alert comes in a seperate Landscape message Machine is ready for reboot
* Choose Info... Power
* Deliver to selected computers as soon as possible
* Error message
I found this thread on reddit about this issue maybe the solution can be
built into the upgrade script
https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
