systemd log

Le
franssoa
Bonjour,

J'ai un serveur sous cherrypy que je souhaite démarrer au boot (ubuntu
serveur 18.04LTS)

J'ai créé un service /home/mon_user/scripts/cherrypy.service :

[Unit]
Description=Serveur Cherrypy
After=mysql.service

[Service]
Type=simple
WorkingDirectory=/home/www/cherrypy/
ExecStart=/home/www/cherrypy/serveur.py
Restart=on-failure
RestartSec0
User=mon_user
Group=mon_user

[Install]
WantedBy=multi-user.target


# cd /etc/systemd/system
# ln -s /home/mon_user/scripts/cherrypy.service
# systemctl daemon-reload
# systemctl enable cherrypy.service
# systemctl start cherrypy.service
# systemctl status cherrypy.service
● cherrypy.service - Serveur Cherrypy
Loaded: loaded (/home/mon_user/scripts/cherrypy.service; enabled;
vendor preset: enabled)
Active: active (running) since Tue 2018-06-05 18:05:14 CEST; 7s ago
Main PID: 1573 (python)
Tasks: 10 (limit: 4915)
CGroup: /system.slice/intranet.service
└─1573 python /home/www/cherrypy/serveur.py

Donc ça démarre, et j'ai un accès fonctionnel au serveur.
Mais après un reboot, le serveur ne se lance pas.

# systemctl daemon-reload
# systemctl status cherrypy.service
● intranet.service - Serveur Cherrypy
Loaded: loaded (/home/mon_user/scripts/cherrypy.service; enabled;
vendor preset: enabled)
Active: inactive (dead)

Où puis-je voir (fichier log) l'erreur que j'ai commise ?

franssoa
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
franssoa
Le #26477568
Le 05. 06. 18 à 18:14, franssoa a écrit :
(...) après un reboot, le serveur ne se lance pas.
# systemctl daemon-reload
# systemctl status cherrypy.service
● intranet.service - Serveur Cherrypy
   Loaded: loaded (/home/mon_user/scripts/cherrypy.service; enabled;
vendor preset: enabled)
   Active: inactive (dead)


Bon j'avance petit à petit.
J'ai déplacé le fichier cherrypy.service directement dans
/etc/systemd/system (sans lien donc) et désormais, après reboot, j'obtiens :
systemd[1548]: cherrypy.service: Failed to execute command: No such file
or directory
systemd[1548]: cherrypy.service: Failed at step EXEC spawning
/usr/bin/python /home/www/cherrypy/serveur.py: No such file or directory
linux4 systemd[1]: cherrypy.service: Main process exited, code=exited,
status 3/EXEC
linux4 systemd[1]: cherrypy.service: Failed with result 'exit-code'.
Comme si le dossier "/home" ou "/usr/bin" pour python n'étaient pas
encore monté avant l'exécution....
franssoa
Marc SCHAEFER
Le #26477579
franssoa
Déplacement de cherrypy.service dans /usr/lib/systemd/user/

En ce qui me concerne, je trouve inquiétant de modifier
des répertoires systèmes. Debian propose un répertoire
où les packages installent (géré par le système de paquet,
fonctionne aussi avec les alternatives p.ex.), ainsi qu'un
répertoire qui a priorité dans /etc [1].
Vérifier aussi que les permissions et les propriétaires/groupes
du fichiers sont similaires à celles des autres fichiers
dans le répertoire où vous l'avez déplacé.
WorkingDirectory=/home/www/cherrypy/
ExecStart=/home/www/cherrypy/serveur.py

Je trouve ce placement aussi inquiétant, si le service tourne
sous un utilisateur qui n'est pas le propriétaire de /home/www
(risque de priviledge escalation -- mais voir plus loin,
c'est un systemd user, pas système, donc pas si grave
que ça).
$ systemctl --user daemon-reload
$ systemctl --user enable intranet

Par contre, je n'ai aucune expérience avec le mode user
de systemctl: à voir cela ne parle pas au même daemon, mais
alors pourquoi lirait-il ses configs de /usr/lib/systemd/user/ et
non pas de ~/.systemd par exemple ? [2]
A voir la référence [2], ils recommandent l'usage de ~/.local
et de ~/.config plutôt que de poser des trucs dans le système.
Dans tous les cas, ce n'est pas le systemd du système, mais
un associé à votre session (voire même moins que ça, je vous
laisse lire et nous expliquer :->)
[1] https://wiki.debian.org/fr/systemd#Cr.2BAOk-er_ou_modifier_des_services
[2] https://wiki.archlinux.org/index.php/Systemd/User
Franssoa
Le #26477622
Le 06/06/2018 à 16:13, Marc SCHAEFER a écrit :
(...) je vous laisse lire et nous expliquer :->)

:-) Merci pour les liens, je vais voir ça à tête reposée.
franssoa
Marc SCHAEFER
Le #26477646
Franssoa
:-) Merci pour les liens, je vais voir ça à tête reposée.

Et si le but est simplement de lancer une application, au démarrage du système,
sous un utilisateur donné, sans dépendre de systemd(8) ou d'autres logiciels
complexes, voici une ancienne technique toujours actuelle, qui en plus utilise
screen(1) pour pouvoir facilement s'attacher au programme lancé plus tard,
créer automatiquement un log I/O, etc (pas obligatoire de passer par
screen, voir plus bas).
Avantage: 100% sous utilisateur normal, pas une seule commande nécessaire
sous root.
su - user
mkdir scripts
cat > scripts/autostart <<EOF
#! /bin/bash
# créer une session screen, détachée
# et logguée (dans ~/screenlog.0 pour
# le premier programme)
screen -L -d -m $0.screen
EOF
chmod u+rx scripts/autostart
cat > scripts/autostart.screen <<EOF
#! /bin/bash
# commande(s) à lancer sous screen(1)
(cd devel/blog && screen ./blog-start.sh)
(cd devel/ptiturl && screen ./ptiturl-start.sh)
EOF
# attention, remplace votre crontab, si elle existe déjà
echo "@reboot /home/user/scripts/autostart" | crontab
cf man 5 crontab
@reboot Run once, at startup.
NB: si vous ne passez pas par screen, si le service ne détache pas, un
processus fils crond(8) y sera attaché et la sortie standard vous sera envoyée
par mail à la terminaison du service (qui ne sera PAS relancé, bien sûr, sauf
si vous le prévoyez dans votre script, avant le prochain reboot).
franssoa
Le #26477718
Le 07. 06. 18 à 06:06, Marc SCHAEFER a écrit :
voici une ancienne technique toujours actuelle (...)

Effectivement c'est mieux ! D'autant plus que mon service sous systemd
ne fonctionne pas. Il ne se lance qu'au log de l'utilisateur...
J'ai donc utilisé cette solution, en y ajoutant un petit délai de 30s
après le boot pour que tout soit démarré (sinon, mon site cherrypy ne se
lance pas)
@reboot sleep 30 && /home/user/scripts/demarre_intranet
et en nommant le screen avec l'option "-S intranet" pour le trouver plus
facilement sans son numéro
$ screen -r intranet
Merci du coup de main
franssoa
Nicolas George
Le #26477752
franssoa , dans le message
Il ne se lance qu'au log de l'utilisateur...

Tu crois que « --user » dans ta ligne de commande veut dire quoi, au
juste ?
Marc SCHAEFER
Le #26477817
franssoa
Effectivement c'est mieux ! D'autant plus que mon service sous systemd
ne fonctionne pas. Il ne se lance qu'au log de l'utilisateur...

D'après la référence que je t'ai mise, systemd-user a deux modes:
a) comme tu dis: à la création de session
b) à l'avance, au démarrage du système
a) peut avoir les variables utiles pour l'accès X11, par exemple
b) ne peut pas donc ne peut servir qu'à des processus qui doivent
effectivement être lancés au démarrage.
J'ai donc utilisé cette solution, en y ajoutant un petit délai de 30s
après le boot pour que tout soit démarré (sinon, mon site cherrypy ne se
lance pas)

Intéressant, il faudrait que cron soit alors lancé plus tard dans systemd:
il y a peut-être une dépendance qui manque (avec sysvinit, cron était
un des derniers trucs lancés).
Marc SCHAEFER
Le #26477819
Marc SCHAEFER
D'après la référence que je t'ai mise, systemd-user a deux modes:

En fait 3: on peut aussi utiliser à n'importe quel moment pour
créer un contexte particulier.
Publicité
Poster une réponse
Anonyme