Con gli script init (o con openrc) potrei sempre eseguire servizi da una diversa root di installazione.
ma quando corro chroot /somepath/to_root /usr/bin/systemctl start someserviceho ottenuto:

Running in chroot, ignoring request.

C'è un modo per forzare l'esecuzione del servizio da parte di systemd?

Aggiornamento:
ho dimenticato di dire che il mio sistema host esegue script di init o openrc, ma mai systemd, e che uso chroot per risolvere i problemi dei sistemi Unix che non possono nemmeno avviare una shell minima.

Un problema ben noto nelle distribuzioni di sistema (Arch Linux, OpenSUSE, Fedora).

Systemd sostituisce sysvinit e offre un grande vantaggio. In sysvinit, quando chiedi a un servizio di avviarsi, eredita il contesto di esecuzione della persona che invoca lo script, che include variabili di ambiente, ulimits e così via. Al contrario Systemd migliora su questo notificando un demone, che avvierà il servizio in un ambiente ben definito, sano e costante, dove ovviamente le prestazioni dei servizi sono molto più facili da prevedere, poiché l'ambiente è sempre lo stesso.

Ciò implica che, quando chiamo systemctl dall'interno del chroot, è irrilevante che io sia all'interno di chroot, l'ambiente che verrà ereditato è ancora quello del PID 1, non quello attuale. Ma c'è di peggio: dato che i socket di comunicazione sono collocati in / run / systemd, un processo in un chroot non sarà nemmeno in grado di parlare con il sistema init!

Quindi, come fai a fare chroot in distrazioni sistemate?

1. Se tutto ciò che vuoi fare è avere un contenitore Linux, questa pagina Wiki Arch ti spiegherà come impostare un contenitore Linux in meno di 30 secondi, grazie a systemd-nspawn.

2. Se invece vuoi davvero un ambiente chroot, questa bellissima e cristallina pagina Web ti fornirà due soluzioni funzionanti (la seconda è una versione modificata di quella offerta al punto 1).

systemd ignora solo i "servizi", quindi eseguo manualmente i comandi daemon.

Quindi invece di

service sshd start

Io uso

/usr/sbin/sshd -D &

Diversi anni dopo devo ammettere che esiste solo una soluzione alla maggior parte dei problemi pratici di Systemd. Perché l'errore è Systemd stesso

Sono davvero stufo di Systemd poiché ho avuto problemi che non ho mai affrontato con cose come Upstart o Openrc:

• L'applicazione di un kernel che richiede il supporto di cgroups (invece di essere resa facoltativa ma abilitata per impostazione predefinita all'interno di un file di configurazione) anche per sistemi embedded con solo 24 Mb di RAM e nessuna memoria scrivibile.
• Nonostante la pretesa di essere modulare, in fase di esecuzione l'inferno delle dipendenze lo rende un forte oggetto divino: vuoi avviare un singolo refs4 rootfs? Non è possibile perché molti programmi richiedono ciò systemd-udevdche richiede systemd-initche richiede il systemd-bootpacchetto che non può essere installato contemporaneamente, grub2né in grado di leggere le immagini del kernel da una partizione reiser4.
• Vuoi connetterti a Internet tramite la connessione Bluetooth? Se non funziona con il tuo telefono Samsung Java Me, non puoi eseguire gli script e il software della riga di comando che in precedenza funzionavano manualmente a causa di networkd.
• Anche se riconosco il problema più grande è se stai costruendo e mantenendo la tua distribuzione Linux: il modulo init systemd stesso ha così tante dipendenze che non puoi proporre di scegliere un altro sistema init attraverso diversi pacchetti di installazione.
• Buona fortuna per la visualizzazione dei registri se non riesci a eseguire il chroot nel tuo sistema o se hai eseguito l'aggiornamento da libdb4.8 (mentre almeno, nel peggiore dei casi Microsoft ha i suoi file di registro in formato XML) .

L'unica soluzione:

Systemd è un complesso inconsistente per la risoluzione di problemi: come alsa invece di ossv4. Quindi, se hai qualcosa che usa systemd, cancella tutti i dati:

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

e installa qualcosa che non lo usa affatto mentre risolve i problemi di SysV Init come Gentoo con Openrc.
Per quanto riguarda la mia domanda, systemd crea cose come il registro di Windows®: se una parte di esso viene rovinata, allora è finita.

No. I servizi vengono eseguiti da systemd (pid 1), non direttamente da systemctl (che invia solo una richiesta di avvio) e poiché systemd viene eseguito al di fuori del chroot, lo stesso vale per il servizio.

Anche se tecnicamente potrebbe essere possibile implementarlo (facendo in modo che systemctl passi in qualche modo la sua radice a systemd), è improbabile che accada poiché esiste già uno strumento per la creazione di container completi ( systemd-nspawn /somepath/to_root). Tuttavia, puoi sempre contattare la mailing list .

Di fronte a questo problema, una volta provato a far apparire la rete in modalità di salvataggio usando la configurazione di rete da chroot. Finalmente questo funziona per me:

service --skip-redirect <service> restart

o:

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

Se stai avviando un servizio inetd con l'attivazione del socket, prendi in considerazione l'avvio di stunnel invece con un file di configurazione che specifica sia un chroot che il tuo binario come destinazione di avvio in stile inetd.

Nota che potresti avere problemi con SELINUX. Su un sistema Oracle Linux 7.1, ho dovuto "chcon -v --type = stunnel_etc_t" su tutti i file che stunnel doveva leggere.

Sarà necessario utilizzare la crittografia TLS sul lato client del socket (ovvero un altro stunnel con "client = yes" nella configurazione). Fammi sapere se vuoi maggiori dettagli su questo.

È possibile utilizzare il nohupcomando per avviare i servizi in chroot. Per iniziare il httpdservizio, ad esempio, lo faccio in questo modo.

nohup httpd /dev/null &

per fermarlo pkill httpd