systemd-login service not started on package install
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| systemd (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt | ||
Bug Description
In systemd 204-0ubuntu1, debian/rules was changed to not restart logind on upgrades.
--- debian/rules 2013-05-22 12:09:59 +0000
+++ debian/rules 2013-06-04 10:46:58 +0000
@@ -179,7 +179,7 @@
- dh_installinit --name systemd-logind --upstart-only
+ dh_installinit --upstart-only --name systemd-logind --no-start
autoreconf:
cp -f /usr/share/
However, the particular usage here -- --no-start -- also means that the service is not started on package install.
I found this because I managed to get my system into a state where logind was not running after boot due to bug #1302264, and then was confused that it still was not running after upgrading libpam-systemd. I think what was wanted here was dh_installinit -r (--no-restart-
The other thing I notice is that the rationale for this is given as:
Do not restart logind on package upgrades, as the cgroup organization changed in this version.
But the *old* prerm script is still going to have stopped logind before the upgrade, which means that any users that upgraded from raring to saucy would have had logind stopped on upgrade. If there were bug reports about such problems at the time, maybe that explains the behavior that was seen...
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: systemd-services 204-5ubuntu17
ProcVersionSign
Uname: Linux 3.13.0-19-generic x86_64
ApportVersion: 2.14-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 9 19:12:59 2014
InstallationDate: Installed on 2010-09-24 (1293 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: systemd
UpgradeStatus: Upgraded to trusty on 2013-10-23 (168 days ago)
Related branches
| Steve Langasek (vorlon) wrote | #1 |
| Changed in systemd (Ubuntu): | |
| assignee: | nobody → Martin Pitt (pitti) |
| Changed in systemd (Ubuntu): | |
| status: | New → In Progress |
| importance: | Undecided → Medium |
| Martin Pitt (pitti) wrote | #2 |
| Martin Pitt (pitti) wrote | #3 |
| Martin Pitt (pitti) wrote | #4 |
| Changed in systemd (Ubuntu): | |
| status: | In Progress → Fix Committed |
| Launchpad Janitor (janitor) wrote | #5 |
| Changed in systemd (Ubuntu): | |
| status: | Fix Committed → Fix Released |
Indeed the --no-start bit is entirely obsolete now. It was only needed for intra-saucy upgrades while it was still in development, so I think it's best to drop it entirely.
On a "real" system that works fine, I tested clean install and upgrades. However, with that it now fails in LXC as mounting /sys/fs/
I think that's what Stéphane's cgroupmanager patch is supposed to handle, isn't it? So we should change the upstart job to do something like that:
- if ! mountpoint -q /sys/fs/
+ if [ ! -e /run/container_type ] && ! mountpoint -q /sys/fs/
# ... mount /sys/fs/
to avoid the failure. With that, the package installs cleanly in LXC, too. Stéphane, does that look correct?