Por que o debian unstable prefere instalar o cgmanager?

1

Eu usei debootstrap e systemd-nspawn para inicializar um container do Debian Unstable. O sistema host era o Debian Jessie.

systemctl mostra que o contêiner tem um serviço com falha, cgproxy . (Instalar cgmanager no host não ajudou, apesar de executar um daemon cgmanager ).

Se eu perguntar apt-get sobre a remoção de cgmanager do contêiner, ele diz para remover systemd-shim e instalar systemd-sysv . Mas aptitude sugere que systemd-shim foi a alternativa preferida.

$ 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)
  • De que especificamente depende libpam-systemd , que pode ser fornecido por um dos systemd-shim ou systemd-sysv ?? A descrição para systemd-sysv diz apenas que tem "páginas manuais e links necessários para o systemd substituir sysvinit".
  • Por que o pacote libpam-systemd prefere systemd-shim over systemd-sysv ?
  • Se eu troquei de modo que não tenha instalado indiretamente systemd-shim e, portanto, cgmanager , perderei alguma funcionalidade esperada?
por sourcejedi 09.05.2017 / 16:58

1 resposta

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".

Acho que é a parte systemd- :-P.

libpam-systemd foi projetado para funcionar em um sistema que foi inicializado com systemd . Alternativamente, se ele inicializar usando um sistema init diferente, ele funcionará com o systemd- shim .

Você foi enganado um pouco pelo nome systemd-sysv . Ele não apenas fornece compatibilidade com versões anteriores para programas do usuário. Ele também define systemd como o sistema init padrão carregado pelo kernel, criando um link simbólico de /sbin/init para /lib/systemd/systemd .

As dependências do pacote libpam-systemd estão assumindo que o SO é inicializado com systemd se e somente se systemd for o sistema init padrão.

CONCLUSÃO: Quando você deseja instalar o systemd na Debian, você geralmente quer instalar o pacote systemd-sysv.

O motivo real pelo qual você está confuso é que você inicializou o contêiner usando systemd-nspawn . Acho que systemd-nspawn procura o sistema init nos locais habituais, e depois volta para o /lib/systemd/systemd .

Se você tentou inicializar esta instalação usando o kernel do Linux, por exemplo, em uma máquina virtual, você teria notado que não tinha configurado o sistema init padrão

    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.");

link

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

Presumivelmente, alguns pacotes de software dependem da libpam-systemd. Quando é puxado como uma dependência, presume-se que você não quer que o systemd-sysv seja instalado se já não estiver marcado como tal. Fazer isso mudaria seu sistema de inicialização! Em vez disso, é preferível instalar o calço de compatibilidade.

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

Não.

    
por 09.05.2017 / 16:58