This bug was fixed in the package init-system-helpers - 1.29ubuntu4
---------------
init-system-helpers (1.29ubuntu4) xenial; urgency=medium
* script/invoke-rc.d: backport change from 1.36 so that logs showing a
failure to start a service with systemd will include the necessary
information to debug, not just instructions to run an additional
command. LP: #1596056.
-- Steve Langasek <steve.langa...@ubuntu.com> Tue, 29 Nov 2016
11:09:41 -0800
** Changed in: init-system-helpers (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1596056
Title:
output of invoke-rc.d for systemd units un-debuggable on failure
Status in init-system-helpers package in Ubuntu:
Fix Released
Status in init-system-helpers source package in Xenial:
Fix Released
Bug description:
[SRU Justification]
Currently if a systemd unit fails to start in a non-interactive upgrade and
all you have is a log, it's impossible to debug. Fix this so that logs contain
the actual details of the unit failure.
[Test case]
1. Get a root shell.
2. Run "sed -e's,sbin/sshd,sbin/sshd-noexists,; /Alias/d'
/lib/systemd/system/ssh.service > /lib/systemd/system/ssh-noexists.service"
3. Run 'systemctl enable ssh-noexists'
4. Run 'ln -s ../init.d/ssh /etc/rc5.d/S02ssh-noexists'
5. Run 'invoke-rc.d ssh-noexists start'
6. Verify that the command directs you to run 'systemctl status' for details,
and provides no details.
7. Install init-system-helpers from -proposed.
8. Run 'invoke-rc.d ssh-noexists start'.
9. Verify that the command provides details about the failure to start
ssh-noexists service.
10. Run 'systemctl disable ssh-noexists'.
11. Run 'rm -f /lib/systemd/system/ssh-noexists.service'.
12. Run 'rm -f /etc/rc5.d/S02ssh-noexists'
[Regression potential]
Minimal. On the failure case, an additional command is run; the additional
command is guarded with || true.
[Original description]
When invoke-rc.d is called on a systemd system, if the unit fails to
start, you get output like:
Created symlink
/etc/systemd/system/multi-user.target.wants/openafs-fileserver.service →
/lib/systemd/system/openafs-fileserver.service.
Job for openafs-fileserver.service failed because the control process exited
with error code.
See "systemctl status openafs-fileserver.service" and "journalctl -xe" for
details.
invoke-rc.d: initscript openafs-fileserver, action "start" failed.
dpkg: error processing package openafs-fileserver (--configure):
subprocess installed post-installation script returned error exit status 1
The output shown here comes from systemctl itself, and is usually
fine. The admin who ran systemctl can run those other commands to
debug.
However, when called by invoke-rc.d, this output is usually seen only
in a log file; maybe submitted in a bug report, maybe attached to
something like an autopkgtest:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
/autopkgtest-yakkety/yakkety/armhf/o/openafs/20160624_174535@/log.gz
By the time someone looks at this log output, it is often too late to
run those commands in order to debug the failure.
invoke-rc.d should call these commands for us on systemd unit failure,
so that the relevant debugging information is included in the log
where it can help.
We don't want to call 'journalctl -xe', which might leak information
into the log from other jobs, but 'journalctl -x -u <this_unit>' may
be appropriate.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1596056/+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
