| 2016-08-24 10:54:38 |
Martin Pitt |
bug |
|
|
added bug |
| 2016-08-24 11:00:53 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
4. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
5. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
6. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-08-24 11:00:58 |
Martin Pitt |
bug |
|
|
added subscriber Thomas Voß |
| 2016-08-24 11:01:02 |
Martin Pitt |
bug |
|
|
added subscriber Steve Langasek |
| 2016-08-24 11:01:07 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2016-08-24 11:01:12 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-08-24 11:01:17 |
Martin Pitt |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-08-24 11:01:17 |
Martin Pitt |
bug task added |
|
systemd (Ubuntu Trusty) |
|
| 2016-08-24 11:01:23 |
Martin Pitt |
systemd (Ubuntu): status |
New |
Invalid |
|
| 2016-08-24 11:01:26 |
Martin Pitt |
systemd (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2016-08-24 11:01:29 |
Martin Pitt |
systemd (Ubuntu Trusty): status |
Confirmed |
Triaged |
|
| 2016-08-24 11:01:31 |
Martin Pitt |
systemd (Ubuntu Trusty): assignee |
|
Martin Pitt (pitti) |
|
| 2016-08-24 11:01:33 |
Martin Pitt |
systemd (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2016-08-24 11:03:22 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
6. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-08-24 11:06:20 |
Martin Pitt |
systemd (Ubuntu Trusty): status |
Triaged |
In Progress |
|
| 2016-09-06 08:23:40 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work.
8. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-09-06 08:36:21 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work.
8. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-09-15 10:44:54 |
Martin Pitt |
bug task added |
|
init-system-helpers (Ubuntu) |
|
| 2016-09-15 10:45:08 |
Martin Pitt |
init-system-helpers (Ubuntu): status |
New |
Invalid |
|
| 2016-09-15 10:56:46 |
Martin Pitt |
init-system-helpers (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-09-15 10:56:46 |
Martin Pitt |
init-system-helpers (Ubuntu Trusty): assignee |
|
Martin Pitt (pitti) |
|
| 2016-09-15 11:02:14 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Run "sudo apt install -y colord && sudo apt purge -y colord". This should succeed.
9. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-11-10 13:59:39 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Run "sudo apt install -y colord && sudo apt purge -y colord". This should succeed.
9. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Run "sudo apt install -y colord && sudo apt purge -y colord". This should succeed.
9. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-11-10 14:01:33 |
Martin Pitt |
description |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive).
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Run "sudo apt install -y colord && sudo apt purge -y colord". This should succeed.
9. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
Rationale: For backporting snapd to 14.04 LTS, we need to provide systemd's service manager (not just logind and auxiliary services like logind or timesyncd). upstart will continue to do the actual booting, and systemd will act as a "deputy init" which by default does not ship with/start any services by itself. We will only support this on server (at the first iteration at least), not on desktops.
Regression potential: This is a new binary package in universe, so existing systems are unaffected (provided that we ensure that the other binary packages do not change and there are no code changes that affect processes other than the "deputy pid 1" service manager). So for plain upgrades the regression potential is very low. However, there is a medium potential for breakage when actually installing the new systemd package, as it might interfere with upstart jobs or other running processes, cause boot/shutdown hangs, etc.
For init-system-helpers, the regression potential is near-zero: We never had (and never will) systemd as pid 1 in trusty, so deb-systemd-invoke was previously never called. It does get called now if you install Ubuntu packages that ship a systemd unit, so we need to make that a no-op to retain the current behaviour.
Test plan:
1. Dist-upgrade a trusty installation to the proposed versions. Ensure this does not pull in "systemd", and that booting, shutdown, desktop startup, suspend on lid close, resume, logout, and user switching all still work.
2. Install the "systemd" binary package (this will replace/remove systemd-shim). Verify that you can talk to the service manager with "sudo systemctl status". Check that booting and shutdown continues to work without (significant) delays.
3. Ensure that "sudo journalctl" works and that "sudo systemctl status systemd-journald" is running and has a few lines of log at the end (unlike what you get when you run systemctl as user).
4. Install a package that ships a systemd .service file, such as "haveged". Ensure that the service file is ignored, "pgrep -af haveged" should only have *one* process and "systemctl status haveged" should not be running (it should not exist, or not be enabled and be inactive). [This part also needs the updated init-system-helpers].
The only services that are running are expected to be systemd-journald.service and systemd-journald.socket.
5. Ensure that the standard targets are active, as that is where third-party/snap services hook into:
systemctl status sysinit.target multi-user.target default.target
6. Install snapd (not in trusty yet, e. g. from Thomas' PPA) and ensure you can install a snap, and its services start after installing the snap and after rebooting.
7. Run "sudo apt-get install --reinstall systemd" to ensure that upgrades to newer systemd trusty versions work. The running systemd should *not* be restarted as that would disrupt snapd and its services (verify that the pid in "initctl status systemd" is the same before and after the upgrade).
8. Run "sudo apt install -y colord && sudo apt purge -y colord". This should succeed.
9. Dist-upgrade to 16.04 to ensure that there are no file conflicts, dependency issues, etc. |
|
| 2016-11-10 15:52:52 |
Steve Langasek |
init-system-helpers (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2016-11-10 15:52:57 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2016-11-10 15:53:08 |
Steve Langasek |
tags |
|
verification-needed |
|
| 2016-11-10 20:01:08 |
Steve Langasek |
systemd (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2016-11-28 08:53:05 |
Po-Hsu Lin |
tags |
verification-needed |
verification-done |
|
| 2016-12-08 15:12:12 |
Martin Pitt |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-12-08 15:12:15 |
Launchpad Janitor |
init-system-helpers (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2016-12-08 15:12:29 |
Launchpad Janitor |
systemd (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2017-01-28 17:12:46 |
Mathew Hodson |
bug task deleted |
init-system-helpers (Ubuntu) |
|
|
| 2017-01-28 17:12:52 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu) |
|
|
