Comment 59 for bug 1325142

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.