It is longstanding practice, predating either upstart or systemd, that
users of Debian and Ubuntu systems should create a /usr/sbin/policy-rc.d
as part of their chroot setup. It is not a bug in the libpam-systemd
package that it tries to start and stop its service using the policy-
declared interface, only to have this fail because you're running in a
chroot and nothing has told the system this.
The fix that was applied to utopic and later is not applicable to
trusty. Later releases "fixed" this problem by removing the upstart
job, no longer needed on systems that run systemd as init. That is not
at all the appropriate fix in trusty.
It is likewise not appropriate to change the libpam-systemd package to
silently ignore failures from invoke-rc.d when trying to start the
systemd-logind service. Such a change would also negatively impact
14.04 systems for the benefit of chroot environments.
This is a systemic problem with the behavior of invoke-rc.d in chroots,
and any fix must also be systemic. This problem is noticeable on the
libpam-systemd package because it's a package that includes an upstart
job but no init script; but many other packages will also misbehave, not
by failing but by *succeeding* and running unsupervised processes that
are not expected to start in the chroot.
So I am marking this bug 'wontfix' for trusty.
The proper package to discuss a fix against is sysvinit, which is where
/usr/sbin/invoke-rc.d comes from in trusty.
I have briefly looked at backporting changes from the xenial /usr/sbin
/invoke-rc.d. However, while the behavior of the xenial version in
chroots appears to be what we're looking for (succeed silently), this
also appears to work only if systemd is detected via the presence of
/run/systemd/system. So this would not solve the problem for all use
cases.
** Changed in: systemd (Ubuntu Trusty)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1325142
Title:
failure to update libpam-systemd in 14.04 due to missing logind init
script
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Trusty:
Won't Fix
Status in systemd source package in Utopic:
Fix Released
Bug description:
Hi,
while running inside an i386 lubuntu 14.04 chroot, upgrading libpam-
systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken
state. 'apt-get -f install' from within the chroot will not fix it,
but if the build is made bootable and put into a iso/VM you can
recover that way in a live session.
the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm
script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind
stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't
exist) and not /etc/init/systemd-logind.conf (does exist).
?
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded.
3 not fully installed or removed.
Need to get 0 B/25.2 kB of archives.
After this operation, 1024 B of additional disk space will be used.
(Reading database ... 113986 files and directories currently installed.)
Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ...
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: warning: subprocess old pre-removal script returned error exit status
100
dpkg: trying script from the new package instead ...
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error processing archive
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack):
subprocess new pre-removal script returned error exit status 100
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error while cleaning up:
subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Our build logs available upon request, but the scripts to setup the chroot to
recreate it are here:
https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh
https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh
In a web-search I notice a few others running into the same bug,
chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28
/%23ubuntu-devel.txt
someone else's build log:
https://launchpad.net/~qutim/+archive/qutim/+build/6039800
launchpad bug #1323575 seems to be a duplicate of this one.
perhaps related to older launchpad bug #1305395 ?
note we are also suffering from a failure with update-initramfs, not sure of
the root cause of that one but I thought I'd mention it in case they were
related, since they both started happening about the same time, a couple weeks
ago. (launchpad bug #1317602)
It all worked ok after the inital releases of 14.04, so something to do with
a package update since then.
thanks,
Hamish
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+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
