Com scripts init (ou com openrc), eu sempre poderia executar serviços de uma raiz de instalação diferente.
mas quando eu corro chroot /somepath/to_root /usr/bin/systemctl start someserviceeu tenho:

Running in chroot, ignoring request.

Existe uma maneira de forçar o systemd a executar o serviço?

Atualização:
Eu esqueci de dizer que meu sistema host executa scripts init ou openrc, mas nunca systemd, e que eu uso o chroot para solucionar problemas de sistemas Unix que nem conseguem iniciar um shell mínimo.

Um problema bem conhecido nas distros do systemd (Arch Linux, OpenSUSE, Fedora).

O Systemd substitui o sysvinit e oferece uma grande vantagem sobre isso. No sysvinit, quando você solicita a inicialização de um serviço, ele herda o contexto de execução da pessoa que está chamando o script, que inclui variáveis ​​de ambiente, ulimits e assim por diante. O Systemd aprimora isso ao contrário, notificando um daemon, que iniciará o serviço em um ambiente bem definido, saudável e constante, onde é claro que os desempenhos dos serviços são muito mais fáceis de prever, pois o ambiente é sempre o mesmo.

Isso implica que, quando chamo systemctl de dentro do chroot, é irrelevante que eu esteja dentro do chroot, o ambiente que será herdado ainda é o do PID 1, não o atual. Mas fica pior do que isso: como os soquetes de comunicação são colocados dentro de / run / systemd, um processo em um chroot nem consegue falar com o sistema init!

Então, como você faz chroot em distribuições systemd?

1. Se tudo que você quer fazer é ter um contêiner Linux, esta página do Arch Wiki lhe dirá como configurar um contêiner Linux em menos de 30 segundos, graças a systemd-nspawn.

2. Se você realmente deseja um ambiente chroot, esta página da Web bonita e cristalina fornecerá duas soluções funcionais (a segunda é uma versão modificada da oferecida no ponto 1).

systemd ignora apenas "serviços", então apenas executo os comandos daemon manualmente.

Então, ao invés de

service sshd start

eu uso

/usr/sbin/sshd -D &

Vários anos depois, devo admitir que há apenas uma solução para a maioria dos problemas práticos do Systemd. Como o erro é o próprio Systemd

Estou realmente farto do Systemd, pois tive problemas que nunca enfrentei em coisas como Upstart ou Openrc:

• A imposição de um kernel que requer suporte a cgroups (em vez de ser opcional, mas ativado por padrão em um arquivo de configuração), mesmo para sistemas embarcados com apenas 24Mb de ram e sem armazenamento gravável.
• Apesar da alegação de ser modular, em tempo de execução, o inferno das dependências o torna um forte objeto divino: deseja inicializar em um único rootfs reiser4? Não é possível porque muitos programas exigem o systemd-udevdque requer systemd-inito systemd-bootpacote que não pode ser instalado ao mesmo tempo e que grub2não pode ler imagens do kernel de uma partição reiser4.
• Deseja conectar-se à Internet através de discagem Bluetooth? Se não funcionar com o seu telefone samsung java me, você não poderá executar os scripts e o software de linha de comando que anteriormente funcionavam manualmente por causa disso networkd.
• Embora reconheça que o maior problema é se você está construindo e mantendo sua própria distribuição Linux: o próprio módulo systemd init tem tantas dependências que você não pode propor a escolha de outro sistema init por meio de diferentes pacotes de instalação.
• Boa sorte para visualizar logs se você não pode executar o chroot no sistema ou se atualizou da libdb4.8 (enquanto, pelo menos, na pior das hipóteses, a Microsoft possui seus arquivos de log no formato xml) .

A única solução :

Systemd é um complexo desnecessário para resolver problemas: como alsa em vez de ossv4. Portanto, se você tem algo que usa o systemd, limpe todos os dados:

dd if=/dev/urandom of=/dev/dm−0 bs=1M

e instale algo que não o use de maneira alguma enquanto soluciona problemas do SysV Init como o Gentoo com o Openrc.
Com relação à minha pergunta, o systemd cria coisas como o registro do Windows®: se uma parte dele é estragada, tudo acaba.

Não. Os serviços são executados pelo systemd (pid 1), não pelo systemctl diretamente (que envia apenas uma solicitação de início) e, como o systemd é executado fora do chroot, o serviço também será executado.

Embora tecnicamente seja possível implementar isso (tornando o systemctl de alguma forma passar sua raiz para o systemd), é pouco provável que isso aconteça, já que já existe uma ferramenta para criar contêineres cheios ( systemd-nspawn /somepath/to_root). Você sempre pode entrar em contato com a lista de discussão .

Diante deste problema, uma vez tentou abrir a rede no modo de recuperação usando a configuração de rede do chroot. Finalmente, isso funciona para mim:

service --skip-redirect <service> restart

ou:

SYSTEMCTL_SKIP_REDIRECT=_ /etc/init.d/<service> restart

Se você estiver iniciando um serviço no estilo inetd com ativação por soquete, considere iniciar stunnel em vez de um arquivo de configuração que especifique um chroot e seu binário como um destino de inicialização no estilo inetd.

Observe que você pode ter problemas com o SELINUX. Em um sistema Oracle Linux 7.1, tive que "chcon -v --type = stunnel_etc_t" em todos os arquivos que o stunnel precisava ler.

Você precisará usar a criptografia TLS no lado do cliente do soquete (ou seja, outro stunnel com "client = yes" na configuração). Deixe-me saber se você quiser mais detalhes sobre isso.

Você pode usar o nohupcomando para iniciar serviços no chroot. Para iniciar o httpdserviço, por exemplo, eu faço assim.

nohup httpd /dev/null &

para parar pkill httpd