Ubuntu-fr

katian

[RESOLU-BIS] : systemd, la suite ...

Salut !

je cherche à comprendre l’Intérêt de liens (symboliques ?) entre /etc/systemd/system & /lib/systemd/system

quelqu'un pourrais m'expliquer ?

Dernière modification par katian (Le 05/11/2020, à 21:23)

bruno

Re : [RESOLU-BIS] : systemd, la suite ...

Bonjour,

Cela sert à activer les services (ou sockets, montages, etc.) en créant un lien symbolique de :
/lib/systemd/system/truc.service vers /etc/systemd/system/cible_requise/truc.service.
Le dossier cible_requise correpondant à la section Install du fichier d'unité systemd

Ces liens sont créés ou supprimés à l'aide des commandes :

systemctl enable truc.service
systemctl disable truc.service 

Dernière modification par bruno (Le 14/09/2018, à 06:25)

katian

Re : [RESOLU-BIS] : systemd, la suite ...

merci bruno

dans mon /home j'ai un service truc.service et dans /etc/systemd/system/ j'ai créé un lien

ln -s /home/katian/truc.service truc.service

j'ai bon ?

bruno

Re : [RESOLU-BIS] : systemd, la suite ...

Non. (et ta commande ne montre pas où est créé le lien symbolique)
Si tu veux créer une unité de service système peronnalisé le mieux est de la placer dans /etc/systemd/system (ou dans $HOME/.config/systemd/user  pour un service spécifique à l'utilisateur). Ce type de fichier n'a rien à faire dans un dossier personnel.

cf. man systemd.unit

katian

Re : [RESOLU-BIS] : systemd, la suite ...

merci bruno je vais donc regarder du coté du

$HOME/.config/systemd/user

katian

Re : [RESOLU-BIS] : systemd, la suite ...

(ou dans $HOME/.config/systemd/user  pour un service spécifique à l'utilisateur).

c'est à ça que sert

systemctl --user

??

LeoMajor

Re : [RESOLU-BIS] : systemd, la suite ...

bonjour,

il y a plusieurs possibilités de path pour insérer ledit script  comme B/**
https: ...//www.freedesktop.org/software/systemd/man/systemd.unit.html
https:..//www.freedesktop.org/software/systemd/man/systemd.service.html

services
A/ type systemctl ou systemctl --system  ; fichier truc.service à placer dans /lib/systemd/system
B/ type systemctl --user ; fichier truc.service  à placer dans  /usr/lib/systemd/user

B/
sudo nano /usr/lib/systemd/user/truc.service  (la seule commande en sudo/root)

[Unit]
Description=... 
Documentation= man:systemd.service

[Install]
WantedBy=default.target 

[Service]
Type=
ExecStart=

La Section [Install] sert principalement à systemctl --user --enable/disable  truc.service  (sans sudo pour  systemctl --user)

readlink /home/toto/.config/systemd/user/default.target.wants/truc.service
/usr/lib/systemd/user/truc.service

systemctl --user start truc.service
systemctl --user status truc.service

katian

Re : [RESOLU-BIS] : systemd, la suite ...

merci LeoMajor

Le problème que je découvre avec un service user

systemctl --user start truc.service

c'est qu'au reboot il n'est pas démarré

un service user peux t'il être démarré au boot ?

LeoMajor

Re : [RESOLU-BIS] : systemd, la suite ...

oui si

sudo loginctl enable-linger toto
loginctl show-user -p Linger toto
Linger=yes

katian

Re : [RESOLU-BIS] : systemd, la suite ...

merci LeoMajor

katian

Re : [RESOLU-BIS] : systemd, la suite ...

bonjour à tou.te.s

autre cas, un

$ loginctl enable-linger

a bien créé le fichier

/var/lib/systemd/linger/katian

mais cela ne semble pas activer un service user bidon que j'ai créé avec

systemctl --user edit --full --force dummy.service

est-ce parce que je suis en ssh sur un serveur ?

un

$ systemctl --user start dummy.service

fonctionne très bien ...

katian

Re : [RESOLU-BIS] : systemd, la suite ...

le service :

$ systemctl --user cat dummy.service 
# /home/katian/.config/systemd/user/dummy.service
[Unit]
Description=dummy service
###After=network-online.target
###Requires=network-online.target

[Service]
Type=simple

###User=katian
###Group=katian

###Nice=+0

ExecStart=/bin/echo "dummy_start"
ExecStop=/bin/echo "dummy_stop"

[Install]
WantedBy=default.target

katian

Re : [RESOLU-BIS] : systemd, la suite ...

j'avance doucement :

après reboot dans une VM ça fonctionne :

$ systemctl --user status dummy.service 
● dummy.service - dummy service
     Loaded: loaded (/home/katian/.config/systemd/user/dummy.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2020-11-05 17:33:53 UTC; 37s ago
    Process: 726 ExecStart=/bin/echo dummy_start (code=exited, status=0/SUCCESS)
    Process: 729 ExecStop=/bin/echo dummy_stop (code=exited, status=0/SUCCESS)
   Main PID: 726 (code=exited, status=0/SUCCESS)

Nov 05 17:33:53 ubuntu-server-vm systemd[693]: Started dummy service.
Nov 05 17:33:53 ubuntu-server-vm systemd[693]: dummy.service: Succeeded.

contrairement à l'autre machine :

$ systemctl --user status dummy.service 
● dummy.service - dummy service
     Loaded: loaded (/home/katian/.config/systemd/user/dummy.service; enabled; vendor preset: enabled)
     Active: inactive (dead)

katian

Re : [RESOLU-BIS] : systemd, la suite ...

j'ai trouvé !

j'avais fait l'essai avec

[Install]
WantedBy=multi-user.target

mais l'unité

multi-user.target

n'est apparemment pas disponible pour un service utilisateur, ceci était resté en 'cache' et avec

$ systemctl --user disable dummy.service
$ systemctl --user enable dummy.service

c'est résolu !

la faute à que j'ai tendance à trop faire confiance à l'auto-complétion, enfin je me comprends