Démarrer un service systemd dans chroot

Question

Avec les scripts init (ou avec openrc), je pouvais toujours exécuter des services à partir d’une racine d’installation différente.
mais quand je lance chroot /somepath/to_root /usr/bin/systemctl start someservice j'ai eu:

Running in chroot, ignoring request.

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

Mettre à jour:
J'ai oublié de dire que mon système hôte exécute les 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.

Answer 1

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

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

• L’application d’un noyau nécessitant la prise en charge de cgroups (au lieu d’être rendue facultative mais activée par défaut dans un fichier de configuration) , même pour les systèmes embarqués comportant uniquement 24 Mo de RAM et pas de stockage 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 rootfs reiser4? Ce n’est pas possible car de nombreux programmes requièrent systemd-udevd, qui requiert systemd-init, ainsi que le paquetage systemd-boot qui ne peut pas être installé en même temps que grub2 et qui ne peut pas lire les 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 le logiciel de ligne de commande qui fonctionnaient auparavant manuellement à cause de networkd.
• Bien que je reconnaisse le plus gros problème, c’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 voir les logs si vous ne pouvez pas chrooter sur votre système ou si vous avez mis à jour depuis libdb4.8 (alors qu'au moins, dans le pire des cas, Microsoft a ses fichiers de log au format xml) .

La seule solution :

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

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

et installez quelque chose qui ne l’utilise pas du tout en résolvant les problèmes de SysV Init comme Gentoo avec Openrc.
Concernant ma question, systemd crée des éléments tels que le registre Windows®: si une partie de celle-ci est foutue, elle est terminée.

Answer 2

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

Systemd remplace sysvinit et offre un avantage considérable par rapport à cela. Dans sysvinit, lorsque vous demandez à un service de démarrer, il hérite du contexte d'exécution de la personne qui appelle le script, qui inclut les variables d'environnement, ulimits, etc. Systemd améliore cela au contraire 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édire, car l'environnement est toujours le même.

Cela implique que, lorsque j'appelle systemctl depuis le chroot, il est indifférent que je sois dans chroot, l'environnement qui sera hérité est toujours celui du PID 1, et non celui actuel. Mais cela devient pire que cela: 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, c'est 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 lieu de cela vous voulez vraiment un environnement chroot, , cette page Web magnifique et limpide vous fournira deux solutions opérationnelles (la seconde est une version modifiée de celui offert au point # 1).

Answer 3

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

Donc au lieu de

service sshd start

J'utilise

/usr/sbin/sshd -D &

Answer 4

Les services sont exécutés par systemd (pid 1), pas directement par systemctl (qui envoie seulement une demande de démarrage). Comme systemd est exécuté en dehors du chroot, le service le sera également.

Bien que techniquement, il soit possible de le mettre en œuvre (en faisant en sorte que systemctl transmette sa racine à systemd), il est peu probable que cela se produise car il existe déjà un outil permettant de créer des conteneurs complets (systemd-nspawn /somepath/to_root). Cependant, vous pouvez toujours contacter la liste de diffusion .

Answer 5

Face à ce problème, une fois essayé de faire apparaître le réseau en mode de secours en utilisant la configuration du réseau de chroot. Enfin cela fonctionne pour moi:

service --skip-redirect <service> restart

ou:

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

Answer 6

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

Notez que vous pouvez avoir des problèmes 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 chiffrement TLS du côté client du socket (c’est-à-dire un autre canal avec "client = yes" dans la configuration). Faites-moi savoir si vous voulez plus de détails à ce sujet.