| 2016-06-24 18:39:07 |
Steve Langasek |
bug |
|
|
added bug |
| 2016-06-24 18:39:23 |
Steve Langasek |
bug |
|
|
added subscriber Martin Pitt |
| 2016-06-28 14:11:26 |
Martin Pitt |
init-system-helpers (Ubuntu): importance |
Undecided |
Wishlist |
|
| 2016-06-28 14:11:26 |
Martin Pitt |
init-system-helpers (Ubuntu): status |
New |
In Progress |
|
| 2016-06-28 14:17:14 |
Martin Pitt |
init-system-helpers (Ubuntu): assignee |
|
Martin Pitt (pitti) |
|
| 2016-06-28 19:27:02 |
Martin Pitt |
init-system-helpers (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2016-06-29 12:50:57 |
Martin Pitt |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-06-29 12:50:57 |
Martin Pitt |
bug task added |
|
init-system-helpers (Ubuntu Xenial) |
|
| 2016-06-29 12:51:00 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2016-06-29 12:51:05 |
Martin Pitt |
init-system-helpers (Ubuntu Xenial): status |
New |
Triaged |
|
| 2016-06-29 12:51:08 |
Martin Pitt |
init-system-helpers (Ubuntu Xenial): importance |
Undecided |
Wishlist |
|
| 2016-06-29 12:51:28 |
Martin Pitt |
init-system-helpers (Ubuntu Xenial): assignee |
|
Martin Pitt (pitti) |
|
| 2016-06-30 16:29:52 |
Launchpad Janitor |
init-system-helpers (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-08-02 16:26:28 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2016-08-02 16:26:30 |
Robie Basak |
tags |
|
server-next |
|
| 2016-11-28 11:03:38 |
Martin Pitt |
init-system-helpers (Ubuntu Xenial): assignee |
Martin Pitt (pitti) |
|
|
| 2016-11-29 19:11:23 |
Steve Langasek |
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. |
[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]
[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. |
|
| 2016-11-29 19:49:07 |
Steve Langasek |
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]
[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. |
[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 'invoke-rc.d ssh-noexists start'
5. Verify that the command directs you to run 'systemctl status' for details, and provides no details.
6. Install init-system-helpers from -proposed.
7. Run 'invoke-rc.d ssh-noexists start'.
8. Verify that the command provides details about the failure to start ssh-noexists service.
9. Run 'systemctl disable ssh-noexists'.
10. Run 'rm -f /lib/systemd/system/ssh-noexists.service'.
[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. |
|
| 2016-11-29 19:49:29 |
Steve Langasek |
init-system-helpers (Ubuntu Xenial): assignee |
|
Steve Langasek (vorlon) |
|
| 2016-11-29 19:50:57 |
Steve Langasek |
init-system-helpers (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2016-11-30 13:06:52 |
Chris J Arges |
init-system-helpers (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-11-30 13:06:54 |
Chris J Arges |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-11-30 13:06:57 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
| 2016-11-30 13:07:05 |
Chris J Arges |
tags |
server-next |
server-next verification-needed |
|
| 2017-03-01 20:30:18 |
Ubuntu Foundations Team Bug Bot |
tags |
server-next verification-needed |
removal-candidate server-next verification-needed |
|
| 2017-03-01 23:08:02 |
Steve Langasek |
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 'invoke-rc.d ssh-noexists start'
5. Verify that the command directs you to run 'systemctl status' for details, and provides no details.
6. Install init-system-helpers from -proposed.
7. Run 'invoke-rc.d ssh-noexists start'.
8. Verify that the command provides details about the failure to start ssh-noexists service.
9. Run 'systemctl disable ssh-noexists'.
10. Run 'rm -f /lib/systemd/system/ssh-noexists.service'.
[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. |
[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. |
|
| 2017-03-01 23:09:03 |
Steve Langasek |
tags |
removal-candidate server-next verification-needed |
server-next verification-done |
|
| 2017-03-09 16:40:57 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-03-09 16:41:09 |
Launchpad Janitor |
init-system-helpers (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
