systemd log

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

franssoa <franssoa@email.invalid> wrote:

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

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

Franssoa <mon@ema.il.invalid> wrote:

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

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

franssoa , dans le message <pfb9eg$kne$1@dont-email.me>, a écrit :

Il ne se lance qu'au log de l'utilisateur...

Tu crois que « --user » dans ta ligne de commande veut dire quoi, au
juste ?

franssoa <franssoa@email.invalid> wrote:

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 <schaefer@alphanet.ch> wrote:

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.