Démarrer un service systemd dans chroot

38

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.

user2284570
la source
1
J'ai également besoin d'exécuter des services dans un chroot, cela fonctionnait toujours avant openrc2, semble impossible maintenant; (
neofutur
Vous essayez de résoudre le mauvais problème. Si vous disposez d'OpenRC, vous devez convertir le service systemd en un service OpenRC. Il n'y a vraiment aucun moyen de contourner cela.
Daniel B
@DanielB: NON! Avez-vous déjà entendu parler de systemrescuecd?
user2284570
Non. Je ne vois pas non plus en quoi cela se rapporte à votre question.
Daniel B

Réponses:

29

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

MariusMatutiae
la source
J'ai cherché systemd-nspawnmais je ne peux pas l'exécuter. Et non, ce n'est pas pour un conteneur car le service doit être utilisé à la fois par l'hôte et l'architecture cible.
user2284570
2
Que je n'utilise jamais systemd dans ma racine de système hôte. Dans mon cas, je ne peux pas mélanger systemd avec openrc.
user2284570
1
@TwoD Cela ne fonctionnera pas. L'exécution systemd-nspawnéchoue avec «Ne fonctionne pas sur un système systemd». sauf si l'hôte utilise également systemd.
DVD
1
@TwoD Et j'ai répondu parce que ça ne me ressemble pas du tout. :) "Je ne peux pas l'exécuter" est une chose étrange à dire si vous avez du mal à trouver l'exécutable, c'est pourquoi je soupçonne que le problème est ce que j'ai mis dans mon commentaire: l'exécuter donne ce message d'erreur et ne fonctionne pas ne fais rien d'utile. Mais même s'il s'avère que le problème était vraiment où trouver systemd-nspawn, alors pointer vers la nouvelle racine n'aidera pas. Soit l'hôte l'a déjà (car il exécute systemd), auquel cas la version hôte peut être utilisée, soit l'hôte ne l'a pas, mais la nouvelle version de la racine ne fonctionnera pas.
hvd
1
systemdrefusera de se présenterchroot
Erkin Alp Güney
4

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 &
johnP
la source
Cela ne fonctionne pas pour tous les services. Certains nécessitent d'être démarrés dans le cadre du démarreur de service système comme Xorg.
user2284570
startxfonctionnera pour Xorg.
Erkin Alp Güney
@ ErkinAlpGüney: pas en chroot… A cause de Dbus.
user2284570
4

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.

utilisateur2284570
la source
3
Veuillez reconnaître que la conception de quelque chose peut vraiment empêcher d'obtenir une réponse, de sorte que la réponse est de passer à quelque chose qui fonctionne . Et que c'est une vraie réponse.
user2284570
1
J'avais la même opinion, maintenant je suis sur une vue un peu plus équilibrée. Systemd a le super gros avantage de pouvoir vraiment tuer ce qui devrait être tué . C'est parce qu'il suit tous les sous-processus bifurqués avec la fonctionnalité de groupe de noyau. Aucun des anciens outils ne peut le faire. De plus, vous souvenez-vous de la merde des scripts dans /etc/init/*.sh?I aussi, mais ce n'est qu'un mauvais souvenir pour moi aujourd'hui. Les fichiers de service systemd sont clairs et comportent environ 10 lignes de configuration . Pas de longs scripts de 200 lignes . Ces énormes avantages ont le systemd, je conviens que toutes ses autres fonctionnalités sont un inconvénient.
Peterh dit réintégrer Monica
Btw, j'ai voté votre réponse parce que, à côté de ses avantages, c'est exactement ce type de critiques, exactement dans ce ton que le développement systemd a besoin d'améliorer. Par exemple, je viens d'essayer de démarrer un postgresql dans un chroot et j'ai dû chier mon système racine pour le faire. Beaucoup, beaucoup de choses merdiques sont toujours là, non.
Peterh dit réintégrer Monica
@peterh: malheureusement tout le monde ne le partage pas, je veux dire au point de supprimer le message. Il ne s'agit pas de SysV init contre Systemd mais plus contre des choses comme Openrc ou même Upstart (qui permet des scripts de démarrage courts ainsi que le démarrage de service parallèle). Au moins, j'ai appris une chose: Darwin est principalement le ᴏꜱ d'Apple ™ Windows est le ᴏꜱ du design Microsoft et Linux est principalement géré par Red Hat. Bien que SysV init, tout en étant plus lent, ne vous limite pas à ce que vous pouvez faire à l'exécution.
user2284570
Les scripts @peterh Services sont également très clairs lorsque vous utilisez Openrc. Le problème avec cgroup sur Systemd est que ce n'est pas une option qui empêche Systemd d'exécuter des choses comme Darwin ou NetBSD.
user2284570
3

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 .

Grawity
la source
1
Bien, mais je dois utiliser systemctl car mon système hôte utilise oepnrc. Je veux une solution indépendante complète
user2284570
3
Je vais encore plus bouer les eaux en disant: Psst! Mentionnez RootDirectory=également, car vous êtes si dangereusement à court de votes positifs. (-:
JdeBP
@JdeBP: Quelle est la différence (en terme de résultats) entre la variable RootDirectoryet la chrootcommande?
user2284570
@grawity: Alors qu'est-ce qui s'ajoute si pid 1c'est init?
user2284570
1

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
point rouge
la source
Agréable. Mais cela ne fonctionne qu'avec les services compatibles Init hérités (ne fonctionnera pas pour la mise en réseau dans Fedora rawhide) . Comme je l'ai dit dans ma réponse, la vraie solution est de bousiller tout ce qui utilise systemd.
user2284570
0

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.

chasser
la source
non, il s'agit de choses comme le d-bus. Je le fais pour diagnostiquer des problèmes sur le chroot cible.
user2284570
-1

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

ellooku
la source
Qu'en est-il des services comme Dbus qui ne peuvent être démarrés que par le script systemd binaire installé?
user2284570
Vous pouvez démarrer ces services à partir de son répertoire avec la commande start.
ellooku
Qui est un lien symbolique contre systemctl. Donc ça ne marche pas.
user2284570
Je le fais tout le temps sur Fedora en cours d'exécution sur mon Android. Peut-être que je ne sais pas quel est votre problème.
ellooku
La conséquence est ce message: Running in chroot, ignoring request.. Je ne pense pas que vous le fassiez tout le temps si chroot. En effet, le script de démarrage nécessite systemd.
user2284570