Systemd : config fichier .service avec fichier sur une autre partition/sous volume BTRFS

Support Debian
, ,
Tags: #<Tag:0x00007f5081a065a8> #<Tag:0x00007f5081a064e0> #<Tag:0x00007f5081a063f0>
#1

Salut les amis,

Pour introduire mon sujet, comme énoncé succintement dans le titre je cherche à configurer un service sous Systemd, dont le fichier se trouve dans un sous-volume BTRFS monté automatiquement au démarrage sur le chemin /srv.

En fait j’ai découvert il y a peu de temps, étant entrain de regarder du côté de Docker, que Linux fournissait des outils de containerisation également, dont LXC et même sous Systemd directement avec “systemd-nspawn”.
Comme c’est donc natif avec systemd je me suis penché sur ce dernier pour bidouiller, apprendre son fonctionnement etc… L’objectif est de pouvoir jouer plus tard avec des machines virtuelles que l’on pourra lancer, bidouiller, détruire à gogo, le tout sans installer de paquets supplémentaires, bref…

Je dois dire que systemd-nspawn fonctionne très bien, il n’y a peut-être pas encore pléthore de commandes à l’instar de celles dispo sous Docker et/ou LXC, mais ça avance pas mal.
Petite précision je suis sous Sid pour ceux qui ne le savent pas déjà, donc pour ceux qui seraient curieux comme moi, les commandes “systemd-nspawn, systemd-machined, machinectl, …” ont été regroupées dans un paquet à part nommé “systemd-container” avec des commandes et fonctionnalités supplémentaires, une connexion internet améliorée pour les machines virtuelles (qq soucis avec la version dans Jessie)…

Bon pour revenir à nos moutons, j’ai donc construit une VM avec systemd-nspawn, plus exactement un serveur DNS Bind9 (debootstrap d’une Debian Jessie et install/config de Bind9 à l’intérieur), dans un dossier nommé “bind9” dans le chemin suivant :

# /srv/bind9

J’ai également crée un dossier “/srv/systemd/system” dans lequel j’ai mis mon fichier “nspawn@bind9.service” (à l’instar des chemins habituels pour systemd qui sont “/etc/systemd/system” et “/lib/systemd/system”)
J’ai donc configuré ce service, mais mon problème est que le chemin parent “/srv” se trouve dans un sous-volume BTRFS qui est monté au démarrage via fstab. Et évidemment le service n’est pas lancé au démarrage du système, je dois le lancer à la mano une fois connecté à mon compte sur l’hôte…

Donc pour préciser ma question, et vu mes connaissances tout de même limitées avec systemd, est-ce que quelqu’un aurait une idée sur le “.service”, “.target”, ou autre option que je devrais rajouter dans mon fichier “nspawn@bind9.service” à l’option :

After=

pour que mon service démarre bien au lancement ou redémarrage du système hôte?

Je m’excuse si j’ai pas été clair ou suffisamment concis en ce moment je fais 36000 choses et la fatigue s’en ressent… :slight_smile:

#2

salut

Liste l’ordonnancement du démarrage

root@debian:/# systemd-analyze blame

Selectionne une cible qui est démarrée avant la tienne, et conditionne le démarrage

avec after=

exemple

[Unit]
Description=Disable power management for wlan0
Requires=sys-subsystem-net-devices-wlan0.device
After=network.target

il y a peut etre un service qui gère ton montage
systemctl status *mount*

#3

Salut,

Oui effectivement c’est ce que je cherche à faire (au passage cette commande est bien pratique) mais je pense que dans mon cas c’est un peu plus subtil et c’est pour ça que je ne trouve pas pour l’instant, si ça se trouve c’est même impossible de le faire comme je veux le faire…

Je m’explique : mes machines virtuelles et les fameux fichiers “exemple.service” sont dans “/srv” qui est dans un sous-volume BTRFS monté automatiquement au démarrage, ça je l’ai déjà dit.
Je n’ai pas fait d’unité “.mount” pour mes sous-volumes, systemd les génère automatiquement au démarrage au travers de “fstab”.

Le truc c’est que si je fais la commande suivante :

# systemctl enable /srv/systemd/system/exemple.service

(au passage cette commande avec de tels attributs ne fonctionne que sous Sid, et eventuellement Testing je suppose, la version de systemd dans Jessie ne permet pas d’activer de cette manière des services qui ne sont pas dans les chemins habituels (/etc/systemd/system, /lib/systemd/system, …), il faut en faire une copie d’abord dans /etc/systemd/system)

systemd va automatiquement créer des liens symboliques de ce fichier vers les chemins suivants :

# /etc/systemd/system/
# /etc/systemd/machines.target.wants

et bref le service est activé pour être lancé au démarrage de la machine. Mais je pense que le problème vient du fait que le chemin vers lequel pointent ces liens symboliques se trouve justement dans un sous-volume différent de celui qui contient la racine système, et qu’au moment où systemd doit lire le contenu des deux chemins ci-dessus, les liens symboliques doivent être marqués comme cassés tant que “/srv” n’est pas monté, et que par la suite lorsque “/srv” est monté évidemment systemd ne relit pas une 2e fois le contenu des deux chemins ci-dessus…
Parce qu’une fois le système démarré et que je me connecte à mon compte utilisateur, avec la commande suivante :

# systemctl status exemple.service

je vois quand même que systemd a bien trouvé le fichier “exemple.service”, il est chargé mais pas activé…

Pour tester une autre approche, j’ai copié directement le fichier “exemple.service” en question dans “/etc/systemd/system” puis fait :

# systemct enable exemple.service

et dans ce cas ça marche le service est bien lancé au démarrage…

J’ai essayé de subordonner le premier cas en ajoutant ceci :

# After=srv.mount

mais ça ne marche pas…

#4

Bon ça n’a pas l’air d’inspirer grand monde… :smiley: