Avec des scripts d'initialisation (ou avec openrc), je pouvais toujours exécuter des services à partir d'une racine d'installation différente.
mais quand je cours chroot /somepath/to_root /usr/bin/systemctl start someservicej'ai:

Running in chroot, ignoring request.

Existe-t-il un moyen de forcer systemd à exécuter le service?

Mise à jour:
j'ai oublié de dire que mon système hôte exécute des scripts init ou openrc, mais jamais systemd, et que j'utilise chroot pour dépanner les systèmes Unix qui ne peuvent même pas lancer un shell minimal.

Un problème bien connu dans les distributions systemd (Arch Linux, OpenSUSE, Fedora).

Systemd remplace sysvinit et offre un grand avantage par rapport à cela. Dans sysvinit, lorsque vous demandez à un service de démarrer, il hérite du contexte d'exécution de la personne appelant le script, qui comprend les variables d'environnement, ulimits, etc. Systemd améliore au contraire cela en notifiant un démon, qui démarrera le service dans un environnement bien défini, sain et constant, où bien sûr les performances des services sont beaucoup plus faciles à prévoir, car l'environnement est toujours le même.

Cela implique que, lorsque j'appelle systemctl depuis le chroot, il n'est pas pertinent que je sois à l'intérieur du chroot, l'environnement qui sera hérité est toujours celui du PID 1, pas mon actuel. Mais c'est encore pire: comme les sockets de communication sont placés dans / run / systemd, un processus dans un chroot ne pourra même pas parler au système init!

Alors, comment allez-vous chrooter dans les distributions système?

1. Si tout ce que vous voulez faire est d'avoir un conteneur Linux, cette page Arch Wiki vous expliquera comment configurer un conteneur Linux en moins de 30 secondes, grâce à systemd-nspawn.

2. Si au contraire vous voulez vraiment un environnement chroot, cette belle page Web limpide vous fournira deux solutions de travail (la seconde est une version modifiée de celle proposée au point # 1).

systemd ignore uniquement les "services", donc je lance juste les commandes du démon manuellement.

Donc au lieu de

service sshd start

j'utilise

/usr/sbin/sshd -D &

Plusieurs années plus tard, je dois admettre qu'il n'y a qu'une seule solution à la plupart des problèmes pratiques de Systemd. Parce que l'erreur est Systemd lui-même

J'ai vraiment marre de Systemd car j'ai eu des problèmes que je n'ai jamais rencontrés avec des choses comme Upstart ou Openrc:

• L'application d'un noyau nécessitant la prise en charge de cgroups (au lieu d'être rendu facultatif mais activé par défaut dans un fichier de configuration) même pour les systèmes embarqués avec seulement 24 Mo de RAM et aucun stockage accessible en écriture.
• Malgré la prétention d'être modulaire, au moment de l'exécution, l'enfer de la dépendance en fait un objet divin fort: vous voulez démarrer sur un seul rootiser reiser4? Ce n'est pas possible car de nombreux programmes nécessitent systemd-udevdce qui nécessite systemd-initqui nécessite le systemd-bootpackage qui ne peut pas être installé en même temps que grub2les images du noyau à partir d'une partition reiser4.
• Vous souhaitez vous connecter à Internet via une connexion Bluetooth? Si cela ne fonctionne pas avec votre téléphone samsung java me, vous ne pouvez pas exécuter les scripts et les logiciels de ligne de commande qui fonctionnaient auparavant manuellement networkd.
• Bien que je reconnaisse que le plus gros problème est si vous construisez et maintenez votre propre distribution Linux: le module init de systemd lui-même a tellement de dépendances que vous ne pouvez pas proposer de choisir un autre système init à travers différents packages d'installation.
• Bonne chance pour afficher les journaux si vous ne pouvez pas chrooter dans votre système ou si vous avez mis à niveau à partir de libdb4.8 (alors qu'au moins, dans le pire des cas, Microsoft a ses fichiers journaux au format xml) .

La seule solution :

Systemd est un complexe inutile pour résoudre les problèmes: comme alsa au lieu d'ossv4. Donc, si vous avez quelque chose qui utilise systemd, effacez simplement toutes les données:

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

et installer quelque chose qui ne l'utilise pas du tout tout en résolvant les problèmes de SysV Init comme Gentoo avec Openrc.
Concernant ma question, systemd crée des choses comme le registre Windows®: si une partie de celui-ci est foutue, alors c'est fini.

Non. Les services sont exécutés par systemd (pid 1), pas par systemctl directement (qui n'envoie qu'une demande de démarrage), et puisque systemd s'exécute en dehors du chroot, le service aussi.

Bien qu'il soit techniquement possible de l'implémenter (en faisant en sorte que systemctl passe sa racine à systemd), il est peu probable qu'il se produise car il existe déjà un outil pour créer des conteneurs pleins ( systemd-nspawn /somepath/to_root). Vous pouvez toujours contacter la liste de diffusion .

Face à ce problème, j'ai essayé une fois de mettre le réseau en mode de secours en utilisant la configuration réseau de chroot. Enfin, cela fonctionne pour moi:

service --skip-redirect <service> restart

ou:

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

Si vous lancez un service de style inetd avec activation de socket, envisagez plutôt de lancer stunnel avec un fichier de configuration qui spécifie à la fois un chroot et votre binaire comme cible de lancement de style inetd.

Notez que vous pouvez avoir des problèmes avec SELINUX. Sur un système Oracle Linux 7.1, je devais "chcon -v --type = stunnel_etc_t" sur tous les fichiers que stunnel devait lire.

Vous devrez utiliser le cryptage TLS du côté client du socket (c'est-à-dire, un autre stunnel avec "client = yes" dans la configuration). Faites-moi savoir si vous souhaitez plus de détails à ce sujet.

Vous pouvez utiliser la nohupcommande pour démarrer les services dans chroot. Pour démarrer le httpdservice par exemple, je le fais comme ça.

nohup httpd /dev/null &

pour l'arrêter pkill httpd