1

I used debootstrap and systemd-nspawn to boot a container of Debian Unstable. The host system was Debian Jessie.

systemctl shows the container has a failed service, cgproxy. (Installing cgmanager on the host did not help, despite running a cgmanager daemon).

If I ask apt-get about removing cgmanager from the container, it says to remove systemd-shim and install systemd-sysv. But aptitude suggests systemd-shim was the preferred alternative.

$ aptitude why cgmanager
i   systemd        Recommends libpam-systemd                        
i A libpam-systemd Depends    systemd-shim (>= 10-3~) | systemd-sysv
i A systemd-shim   Depends    cgmanager (>= 0.32)
  • What specifically does libpam-systemd depend on, which can be provided by either one of systemd-shim or systemd-sysv?? The description for systemd-sysv only says it has "manual pages and links needed for systemd to replace sysvinit".
  • Why does the libpam-systemd package prefer systemd-shim over systemd-sysv?
  • If I switched it so I hadn't indirectly installed systemd-shim and thus cgmanager, am I going to be losing any expected functionality?

1 Answer 1

1

What specifically does libpam-systemd depend on, which can be provided by either one of systemd-shim or systemd-sysv?? The description for systemd-sysv only says it has "manual pages and links needed for systemd to replace sysvinit".

I think it's the systemd- part :-P.

libpam-systemd is designed to work on a system which was booted with systemd. Alternatively, if it boots using a different init system, it will work with systemd-shim.

You were misled somewhat by the name systemd-sysv. It doesn't just provide backwards compatibility for user programs. It also sets systemd as the default init system loaded by the kernel, by creating a symlink from /sbin/init to /lib/systemd/systemd.

The libpam-systemd package dependencies are assuming that the OS is booted with systemd if and only if systemd is the default init system.

CONCLUSION: When you want to install systemd in Debian, you generally want to install the systemd-sysv package.

The real reason you're confused is that you booted the container using systemd-nspawn. I think systemd-nspawn searches for the init system in the usual places, and then falls back to the /lib/systemd/systemd.

If you'd tried to boot this install using the Linux kernel e.g. in a virtual machine, you would have noticed that you hadn't set up default init system

    if (!try_to_run_init_process("/sbin/init") ||
        !try_to_run_init_process("/etc/init") ||
        !try_to_run_init_process("/bin/init") ||
        !try_to_run_init_process("/bin/sh"))
        return 0;

    panic("No working init found.  Try passing init= option to kernel. "
"See Linux Documentation/admin-guide/init.rst for guidance.");

https://github.com/torvalds/linux/blob/v4.11/init/main.c#L990

Why does the libpam-systemd package prefer systemd-shim over systemd-sysv?

Presumably some software packages depend on libpam-systemd. When it's pulled in as a dependency, it's assumed that you don't want systemd-sysv installed if it isn't already marked as such. Doing so would change your init system! Instead, it's preferred to install the compatibility shim.

If I switched it so I hadn't indirectly installed systemd-shim and thus cgmanager, am I going to be losing any expected functionality?

Nope.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .