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:
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.
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. fileserver. service failed because the control process exited with error code. fileserver. service" and "journalctl -xe" for details.
Job for openafs-
See "systemctl status openafs-
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_77e2ada1e7 a84929a74ba3b87 153c0ac/ 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.