Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
franssoa
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
Le 05. 06. 18 à 18:14, franssoa a écrit :
(...) après un reboot, le serveur ne se lance pas.
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....
(...) 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
franssoa 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é.
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).
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 <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é.
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).
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 :->)
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é.
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).
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 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
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.
:-) Merci pour les liens, je vais voir ça à tête reposée. franssoa
Marc SCHAEFER
Franssoa 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).
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)
# 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).
:-) 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 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
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)
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
franssoa , dans le message <pfb9eg$kne$, 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 , 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 , dans le message <pfb9eg$kne$, 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 ?
Marc SCHAEFER
franssoa 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).
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).
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
Marc SCHAEFER 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.
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.