Geneweb, logiciel de généalogie, est installé depuis longtemps dans sa
version 6.08 à bord de mon raspberrypi. J'ai encore créé récemment une base
en utilisant l'outil graphique gwsetup, outil qui était donc fonctionnel ce
jour-là puisque toutes mes bases sont accessibles depuis mon pc de bureau
dans mon navigateur web à l'adresse http://192.168.1.33:2317/$Base. Je peux
ajouter des personnes, les modifier, les supprimer, etc, sans souci.
Le problème : Depuis quelques jours, le daemon gwsetup qui permet
normalement, en mode graphique depuis mon pc dans le même navigateur, de
gérer les bases, d'importer et exporter des fichiers gedcom, etc, n'est pas
accessible. Quand je tape son adresse http://192.168.1.33:2316 j'obtiens un
message connexion refusée.
J'ai tenté maintes fois de relancer ce daemon diabolique, et même redémarré
le raspberrypi mais il y a comme un os. Voici ce que ça donne dans ma
session ssh :
pi@raspberrypi:~ $ systemctl status gwsetup
● gwsetup.service - LSB: Geneweb setup web interface
Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled)
Active: active (exited) since Thu 2019-04-11 17:14:30 CEST; 19min ago
Docs: man:systemd-sysv-generator(8)
Process: 2674 ExecStop=/etc/init.d/gwsetup stop (code=exited,
status=0/SUCCESS)
Process: 2681 ExecStart=/etc/init.d/gwsetup start (code=exited,
status=0/SUCCESS)
avril 11 17:14:30 raspberrypi systemd[1]: Starting LSB: Geneweb setup web
interface...
avril 11 17:14:30 raspberrypi gwsetup[2681]: Starting gwsetup server gwsetup.
avril 11 17:14:30 raspberrypi systemd[1]: Started LSB: Geneweb setup web
interface.
pi@raspberrypi:~ $ sudo systemctl restart gwsetup
pi@raspberrypi:~ $ systemctl status gwsetup
● gwsetup.service - LSB: Geneweb setup web interface
Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled)
Active: active (exited) since Thu 2019-04-11 17:35:01 CEST; 36s ago
Docs: man:systemd-sysv-generator(8)
Process: 2836 ExecStop=/etc/init.d/gwsetup stop (code=exited,
status=0/SUCCESS)
Process: 2843 ExecStart=/etc/init.d/gwsetup start (code=exited,
status=0/SUCCESS)
avril 11 17:35:00 raspberrypi systemd[1]: Starting LSB: Geneweb setup web
interface...
avril 11 17:35:01 raspberrypi gwsetup[2843]: Starting gwsetup server gwsetup.
avril 11 17:35:01 raspberrypi systemd[1]: Started LSB: Geneweb setup web
interface.
Je précise que dans le fichier /etc/geneweb/gwsetup_only.txt j'ai bien mis
192.168.1.20 qui est l'adresse ip de mon pc.
Je ne comprends pas cette notion de daemon "active (exited)" bien qu'elle
soit le sujet de nombreuses discussions sur le net. Ce que je peux dire
c'est qu'aucun processus gwsetup n'est en cours d'exécution, selon la
réponse à la commande ps -A.
Un utilisateur expérimenté de geneweb serait sûrement le plus qualifié mais
j'accepte l'aide de tout le monde. Merci d'avance.
:~ $ systemctl status gwsetup ? gwsetup.service - LSB: Geneweb setup web interface Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled) Active: active (exited) since Thu 2019-04-11 17:14:30 CEST; 19min ago Docs: man:systemd-sysv-generator(8) Process: 2674 ExecStop=/etc/init.d/gwsetup stop (code=exited, status=0/SUCCESS) Process: 2681 ExecStart=/etc/init.d/gwsetup start (code=exited, status=0/SUCCESS)
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe' (qui résume simplement certains logs de /var/log), ou des logs spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?) En alternative il y a toujours la possibilité de faire un sudo -s # devenir root (s'il y a un pw root: juste su) su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash # puis de lancer avec des options similaires à ce que fait systemd. pour voir le message d'erreur s'il n'y a pas de logs. On peut aussi consulter le log du kernel à tout hasard où certains crashes peuvent être signalés: dmesg (ou sudo dmesg)
pi@raspberrypi:~ $ systemctl status gwsetup
? gwsetup.service - LSB: Geneweb setup web interface
Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled)
Active: active (exited) since Thu 2019-04-11 17:14:30 CEST; 19min ago
Docs: man:systemd-sysv-generator(8)
Process: 2674 ExecStop=/etc/init.d/gwsetup stop (code=exited,
status=0/SUCCESS)
Process: 2681 ExecStart=/etc/init.d/gwsetup start (code=exited,
status=0/SUCCESS)
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe'
(qui résume simplement certains logs de /var/log), ou des logs
spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)
En alternative il y a toujours la possibilité de faire un
sudo -s # devenir root (s'il y a un pw root: juste su)
su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash
# puis de lancer avec des options similaires à ce que fait systemd.
pour voir le message d'erreur s'il n'y a pas de logs.
On peut aussi consulter le log du kernel à tout hasard où certains
crashes peuvent être signalés: dmesg (ou sudo dmesg)
:~ $ systemctl status gwsetup ? gwsetup.service - LSB: Geneweb setup web interface Loaded: loaded (/etc/init.d/gwsetup; generated; vendor preset: enabled) Active: active (exited) since Thu 2019-04-11 17:14:30 CEST; 19min ago Docs: man:systemd-sysv-generator(8) Process: 2674 ExecStop=/etc/init.d/gwsetup stop (code=exited, status=0/SUCCESS) Process: 2681 ExecStart=/etc/init.d/gwsetup start (code=exited, status=0/SUCCESS)
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe' (qui résume simplement certains logs de /var/log), ou des logs spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?) En alternative il y a toujours la possibilité de faire un sudo -s # devenir root (s'il y a un pw root: juste su) su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash # puis de lancer avec des options similaires à ce que fait systemd. pour voir le message d'erreur s'il n'y a pas de logs. On peut aussi consulter le log du kernel à tout hasard où certains crashes peuvent être signalés: dmesg (ou sudo dmesg)
Geo Cherchetout
Le 12/04/2019 09:52, *Marc SCHAEFER* a écrit :
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe' (qui résume simplement certains logs de /var/log), ou des logs spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)
Je ne trouve ni geneweb.log ni gwsetup.log mais c'est peut-être parce que j'ai mal configuré syslog-ng ou parce que /var/log/ est monté en mémoire vive ? En revanche journalctl -xe immédiatement après avoir tenté un nouveau « restart » de gwsetup donne ceci, je ne recopie que la fin : -- Une nouvelle session a été créée pour l'utilisateur pi avec -- l'identifiant (ID) c7. -- -- Le processus maître de la session est 8700. avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory avril 12 14:23:13 raspberrypi CRON[8689]: (CRON) info (No MTA installed, discarding output) avril 12 14:23:13 raspberrypi CRON[8689]: pam_unix(cron:session): session closed for user root avril 12 14:23:19 raspberrypi sudo[8736]: pi : TTY=pts/2 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl restart gwsetup avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session opened for user root by pi(uid=0) avril 12 14:23:19 raspberrypi systemd[1]: Stopping LSB: Geneweb setup web interface... -- Subject: L'unité (unit) gwsetup.service a commencé à s'arrêter -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a commencé à s'arrêter. avril 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup. avril 12 14:23:19 raspberrypi systemd[1]: Stopped LSB: Geneweb setup web interface. -- Subject: L'unité (unit) gwsetup.service a terminé son arrêt -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a terminé son arrêt. avril 12 14:23:19 raspberrypi systemd[1]: Starting LSB: Geneweb setup web interface... -- Subject: L'unité (unit) gwsetup.service a commencé à démarrer -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a commencé à démarrer. avril 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup. avril 12 14:23:19 raspberrypi systemd[1]: Started LSB: Geneweb setup web interface. -- Subject: L'unité (unit) gwsetup.service a terminé son démarrage -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a terminé son démarrage, avec le résultat done. avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session closed for user root Ça semble correct mais ça ne l'est pas réellement puisque je n'ai toujours pas de processus gwsetup. (À la différence de ce que j'observe sur un autre ordinateur sous debian stretch où la même version de geneweb est installée.)
En alternative il y a toujours la possibilité de faire un sudo -s # devenir root (s'il y a un pw root: juste su) su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash # puis de lancer avec des options similaires à ce que fait systemd.
J'arrive à devenir l'utilisateur geneweb mais je cherche en vain la commande exacte lancée par systemd. Même sur l'autre ordinateur où gwsetup fonctionne bien, cette commande n'apparaît dans aucun des fichiers de log que j'ai visités ni dans dmesg. Peut-on la déduire du contenu de /etc/init.d/gwsetup ci-dessous recopié : $ cat gwsetup #! /bin/sh # # GeneWeb Start the Gwsetup mini HTTP server. # ### BEGIN INIT INFO # Provides: gwsetup # Required-Start: $network $local_fs $remote_fs geneweb # Should-Start: # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Should-Stop: # Short-Description: Geneweb setup web interface ### END INIT INFO # Do not change the values below GENEWEBSHARE=/usr/share/geneweb GENEWEBDB=/var/lib/geneweb GENEWEBUSER=geneweb DAEMON=/usr/bin/gwsetup WRAPPER=/usr/lib/geneweb/gwsetup.wrapper NAME=gwsetup LOGFILE=/var/log/$NAME.log GWSETUPONLYFILE=/etc/geneweb/gwsetup_only.txt # Defaults # The port which the daemon listens to GWSETUP_PORT#16 # The default language LNG=en # Run Mode : if anything else than "daemon", no daemon will be # launched automatically RUN_MODE="Always on" # Additionnal options OPTIONS="" # Reads geneweb config file (for language) [ -r /etc/default/geneweb ] && . /etc/default/geneweb # Reads gwsetup config file (for other settings) [ -r /etc/default/gwsetup ] && . /etc/default/gwsetup # Export variables so that they may be used by the wrapper script export LNG GWSETUP_PORT LOGFILE NAME DAEMON GENEWEBDB GENEWEBDOC GENEWEBSHARE GWSETUPONLYFILE OPTIONS trap "" 1 test -f $DAEMON || exit 0 . /lib/lsb/init-functions # We start (or stop) the daemon only when configured # for running in daemon mode if [ "$RUN_MODE" != "Always on" ]; then exit 0 fi start_stop() { case "$1" in start) log_begin_msg "Starting gwsetup server" "gwsetup" if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER; then log_end_msg 1 exit 1 fi log_end_msg 0 ;; stop) log_begin_msg "Stopping gwsetup server" "gwsetup" start-stop-daemon --stop --quiet --exec $DAEMON -- -gd $GENEWEBSHARE -only $GWSETUPONLYFILE -lang$LANG -daemon log_end_msg 0 ;; restart | force-reload) start_stop stop sleep 2 start_stop start ;; *) log_success_msg "Usage: /etc/init.d/$NAME {start|stop|restart|force-reload}" exit 1 ;; esac } start_stop "$@" exit 0
Le 12/04/2019 09:52, *Marc SCHAEFER* a écrit :
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe'
(qui résume simplement certains logs de /var/log), ou des logs
spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)
Je ne trouve ni geneweb.log ni gwsetup.log mais c'est peut-être parce que
j'ai mal configuré syslog-ng ou parce que /var/log/ est monté en mémoire vive ?
En revanche journalctl -xe immédiatement après avoir tenté un nouveau «
restart » de gwsetup donne ceci, je ne recopie que la fin :
-- Une nouvelle session a été créée pour l'utilisateur pi avec
-- l'identifiant (ID) c7.
--
-- Le processus maître de la session est 8700.
avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat
/var/log/lastlog: No such file or directory
avril 12 14:23:13 raspberrypi CRON[8689]: (CRON) info (No MTA installed,
discarding output)
avril 12 14:23:13 raspberrypi CRON[8689]: pam_unix(cron:session): session
closed for user root
avril 12 14:23:19 raspberrypi sudo[8736]: pi : TTY=pts/2 ;
PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl restart gwsetup
avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session
opened for user root by pi(uid=0)
avril 12 14:23:19 raspberrypi systemd[1]: Stopping LSB: Geneweb setup web
interface...
-- Subject: L'unité (unit) gwsetup.service a commencé à s'arrêter
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a commencé à s'arrêter.
avril 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup.
avril 12 14:23:19 raspberrypi systemd[1]: Stopped LSB: Geneweb setup web
interface.
-- Subject: L'unité (unit) gwsetup.service a terminé son arrêt
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a terminé son arrêt.
avril 12 14:23:19 raspberrypi systemd[1]: Starting LSB: Geneweb setup web
interface...
-- Subject: L'unité (unit) gwsetup.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a commencé à démarrer.
avril 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup.
avril 12 14:23:19 raspberrypi systemd[1]: Started LSB: Geneweb setup web
interface.
-- Subject: L'unité (unit) gwsetup.service a terminé son démarrage
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) gwsetup.service a terminé son démarrage, avec le résultat
done.
avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session
closed for user root
Ça semble correct mais ça ne l'est pas réellement puisque je n'ai toujours
pas de processus gwsetup. (À la différence de ce que j'observe sur un autre
ordinateur sous debian stretch où la même version de geneweb est installée.)
En alternative il y a toujours la possibilité de faire un
sudo -s # devenir root (s'il y a un pw root: juste su)
su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash
# puis de lancer avec des options similaires à ce que fait systemd.
J'arrive à devenir l'utilisateur geneweb mais je cherche en vain la commande
exacte lancée par systemd. Même sur l'autre ordinateur où gwsetup fonctionne
bien, cette commande n'apparaît dans aucun des fichiers de log que j'ai
visités ni dans dmesg. Peut-on la déduire du contenu de /etc/init.d/gwsetup
ci-dessous recopié :
$ cat gwsetup
#! /bin/sh
#
# GeneWeb Start the Gwsetup mini HTTP server.
#
### BEGIN INIT INFO
# Provides: gwsetup
# Required-Start: $network $local_fs $remote_fs geneweb
# Should-Start:
# Required-Stop: $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Should-Stop:
# Short-Description: Geneweb setup web interface
### END INIT INFO
# Do not change the values below
GENEWEBSHARE=/usr/share/geneweb
GENEWEBDB=/var/lib/geneweb
GENEWEBUSER=geneweb
DAEMON=/usr/bin/gwsetup
WRAPPER=/usr/lib/geneweb/gwsetup.wrapper
NAME=gwsetup
LOGFILE=/var/log/$NAME.log
GWSETUPONLYFILE=/etc/geneweb/gwsetup_only.txt
# Defaults
# The port which the daemon listens to
GWSETUP_PORT#16
# The default language
LNG=en
# Run Mode : if anything else than "daemon", no daemon will be
# launched automatically
RUN_MODE="Always on"
# Additionnal options
OPTIONS=""
# Export variables so that they may be used by the wrapper script
export LNG GWSETUP_PORT LOGFILE NAME DAEMON GENEWEBDB GENEWEBDOC
GENEWEBSHARE GWSETUPONLYFILE OPTIONS
trap "" 1
test -f $DAEMON || exit 0
. /lib/lsb/init-functions
# We start (or stop) the daemon only when configured
# for running in daemon mode
if [ "$RUN_MODE" != "Always on" ]; then
exit 0
fi
start_stop()
{
case "$1" in
start)
log_begin_msg "Starting gwsetup server" "gwsetup"
if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec
$WRAPPER; then
log_end_msg 1
exit 1
fi
log_end_msg 0
;;
N'y aurait-il pas des logs de ce daemon spécifique via `journalctl -xe' (qui résume simplement certains logs de /var/log), ou des logs spécifiques à ce programme (p.ex. dans /var/log/genetruc/argh.log ?)
Je ne trouve ni geneweb.log ni gwsetup.log mais c'est peut-être parce que j'ai mal configuré syslog-ng ou parce que /var/log/ est monté en mémoire vive ? En revanche journalctl -xe immédiatement après avoir tenté un nouveau « restart » de gwsetup donne ceci, je ne recopie que la fin : -- Une nouvelle session a été créée pour l'utilisateur pi avec -- l'identifiant (ID) c7. -- -- Le processus maître de la session est 8700. avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory avril 12 14:23:04 raspberrypi sshd[8700]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory avril 12 14:23:13 raspberrypi CRON[8689]: (CRON) info (No MTA installed, discarding output) avril 12 14:23:13 raspberrypi CRON[8689]: pam_unix(cron:session): session closed for user root avril 12 14:23:19 raspberrypi sudo[8736]: pi : TTY=pts/2 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl restart gwsetup avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session opened for user root by pi(uid=0) avril 12 14:23:19 raspberrypi systemd[1]: Stopping LSB: Geneweb setup web interface... -- Subject: L'unité (unit) gwsetup.service a commencé à s'arrêter -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a commencé à s'arrêter. avril 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup. avril 12 14:23:19 raspberrypi systemd[1]: Stopped LSB: Geneweb setup web interface. -- Subject: L'unité (unit) gwsetup.service a terminé son arrêt -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a terminé son arrêt. avril 12 14:23:19 raspberrypi systemd[1]: Starting LSB: Geneweb setup web interface... -- Subject: L'unité (unit) gwsetup.service a commencé à démarrer -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a commencé à démarrer. avril 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup. avril 12 14:23:19 raspberrypi systemd[1]: Started LSB: Geneweb setup web interface. -- Subject: L'unité (unit) gwsetup.service a terminé son démarrage -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- L'unité (unit) gwsetup.service a terminé son démarrage, avec le résultat done. avril 12 14:23:19 raspberrypi sudo[8736]: pam_unix(sudo:session): session closed for user root Ça semble correct mais ça ne l'est pas réellement puisque je n'ai toujours pas de processus gwsetup. (À la différence de ce que j'observe sur un autre ordinateur sous debian stretch où la même version de geneweb est installée.)
En alternative il y a toujours la possibilité de faire un sudo -s # devenir root (s'il y a un pw root: juste su) su - l-utilisateur-qui-tourne-habituellement-ce-service -s /bin/bash # puis de lancer avec des options similaires à ce que fait systemd.
J'arrive à devenir l'utilisateur geneweb mais je cherche en vain la commande exacte lancée par systemd. Même sur l'autre ordinateur où gwsetup fonctionne bien, cette commande n'apparaît dans aucun des fichiers de log que j'ai visités ni dans dmesg. Peut-on la déduire du contenu de /etc/init.d/gwsetup ci-dessous recopié : $ cat gwsetup #! /bin/sh # # GeneWeb Start the Gwsetup mini HTTP server. # ### BEGIN INIT INFO # Provides: gwsetup # Required-Start: $network $local_fs $remote_fs geneweb # Should-Start: # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Should-Stop: # Short-Description: Geneweb setup web interface ### END INIT INFO # Do not change the values below GENEWEBSHARE=/usr/share/geneweb GENEWEBDB=/var/lib/geneweb GENEWEBUSER=geneweb DAEMON=/usr/bin/gwsetup WRAPPER=/usr/lib/geneweb/gwsetup.wrapper NAME=gwsetup LOGFILE=/var/log/$NAME.log GWSETUPONLYFILE=/etc/geneweb/gwsetup_only.txt # Defaults # The port which the daemon listens to GWSETUP_PORT#16 # The default language LNG=en # Run Mode : if anything else than "daemon", no daemon will be # launched automatically RUN_MODE="Always on" # Additionnal options OPTIONS="" # Reads geneweb config file (for language) [ -r /etc/default/geneweb ] && . /etc/default/geneweb # Reads gwsetup config file (for other settings) [ -r /etc/default/gwsetup ] && . /etc/default/gwsetup # Export variables so that they may be used by the wrapper script export LNG GWSETUP_PORT LOGFILE NAME DAEMON GENEWEBDB GENEWEBDOC GENEWEBSHARE GWSETUPONLYFILE OPTIONS trap "" 1 test -f $DAEMON || exit 0 . /lib/lsb/init-functions # We start (or stop) the daemon only when configured # for running in daemon mode if [ "$RUN_MODE" != "Always on" ]; then exit 0 fi start_stop() { case "$1" in start) log_begin_msg "Starting gwsetup server" "gwsetup" if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER; then log_end_msg 1 exit 1 fi log_end_msg 0 ;; stop) log_begin_msg "Stopping gwsetup server" "gwsetup" start-stop-daemon --stop --quiet --exec $DAEMON -- -gd $GENEWEBSHARE -only $GWSETUPONLYFILE -lang$LANG -daemon log_end_msg 0 ;; restart | force-reload) start_stop stop sleep 2 start_stop start ;; *) log_success_msg "Usage: /etc/init.d/$NAME {start|stop|restart|force-reload}" exit 1 ;; esac } start_stop "$@" exit 0
Geo Cherchetout
Pardon, j'ai quand même une petite trace dans /var/log/syslog mais ça ne m'aide pas vraiment : :/etc/init.d $ grep gw /var/log/syslog Apr 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup. Apr 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup.
Pardon, j'ai quand même une petite trace dans /var/log/syslog mais ça ne
m'aide pas vraiment :
Pardon, j'ai quand même une petite trace dans /var/log/syslog mais ça ne m'aide pas vraiment : :/etc/init.d $ grep gw /var/log/syslog Apr 12 14:23:19 raspberrypi gwsetup[8742]: Stopping gwsetup server gwsetup. Apr 12 14:23:19 raspberrypi gwsetup[8749]: Starting gwsetup server gwsetup.
Marc SCHAEFER
In article <q8q4s6$2oc5$ you wrote:
En revanche journalctl -xe immédiatement après avoir tenté un nouveau « restart » de gwsetup donne ceci, je ne recopie que la fin :
Faites-voir plutôt un - reboot de votre pi - vérification avec ps auxw | grep gwsetup qu'il n'est pas lancé - systemctl gwsetup stop - systemctl gwsetup start ensuite regardez s'il est lancé, puis consultez à nouveau les logs (ls -lart /var/log # t pour sort-by-time) et le journalctl -xe. systemctl restart fait un stop ce qui pollue les logs, à voir.
In article <q8q4s6$2oc5$1@news.gegeweb.eu> you wrote:
En revanche journalctl -xe immédiatement après avoir tenté un nouveau «
restart » de gwsetup donne ceci, je ne recopie que la fin :
Faites-voir plutôt un
- reboot de votre pi
- vérification avec ps auxw | grep gwsetup
qu'il n'est pas lancé
- systemctl gwsetup stop
- systemctl gwsetup start
ensuite regardez s'il est lancé, puis consultez à nouveau
les logs (ls -lart /var/log # t pour sort-by-time) et
le journalctl -xe.
systemctl restart fait un stop ce qui pollue les logs,
à voir.
En revanche journalctl -xe immédiatement après avoir tenté un nouveau « restart » de gwsetup donne ceci, je ne recopie que la fin :
Faites-voir plutôt un - reboot de votre pi - vérification avec ps auxw | grep gwsetup qu'il n'est pas lancé - systemctl gwsetup stop - systemctl gwsetup start ensuite regardez s'il est lancé, puis consultez à nouveau les logs (ls -lart /var/log # t pour sort-by-time) et le journalctl -xe. systemctl restart fait un stop ce qui pollue les logs, à voir.
Marc SCHAEFER
Geo Cherchetout wrote:
contenu de /etc/init.d/gwsetup
Avec systemd, il se pourrait que cela ne soit pas ce script qui soit exécuté, il faudrait encore vérifier cela, p.ex. avec systemctl status gwsetup.service P.ex. chez moi avec bind9: /lib/systemd/system/bind9.service qui exécute ExecStart=/usr/sbin/named -f $OPTIONS (et donc ignore superbement tout changement à /etc/init.d/bind9, qui n'est là que pour la compatibilité). Vous pourriez modifier le script init de gwsetup, en supposant que c'est le bon, pour: log_begin_msg "Starting gwsetup server" "gwsetup" if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER; then log_end_msg 1 exit 1 fi ajouter un "echo" du genre echo start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER et vous aurez les arguments complets (mais peut-être pas certaines variables d'environnement). Et éventuellement consulter le script $WRAPPER pour voir comment il lance. Puis ajouter les arguments de debugging nécessaires.
Avec systemd, il se pourrait que cela ne soit pas ce script qui
soit exécuté, il faudrait encore vérifier cela, p.ex. avec
systemctl status gwsetup.service
P.ex. chez moi avec bind9:
/lib/systemd/system/bind9.service
qui exécute ExecStart=/usr/sbin/named -f $OPTIONS
(et donc ignore superbement tout changement à
/etc/init.d/bind9, qui n'est là que pour la
compatibilité).
Vous pourriez modifier le script init de gwsetup,
en supposant que c'est le bon, pour:
log_begin_msg "Starting gwsetup server" "gwsetup"
if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec
$WRAPPER; then
log_end_msg 1
exit 1
fi
ajouter un "echo" du genre
echo start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER
et vous aurez les arguments complets (mais peut-être pas certaines
variables d'environnement).
Et éventuellement consulter le script $WRAPPER pour voir comment il
lance.
Puis ajouter les arguments de debugging nécessaires.
Avec systemd, il se pourrait que cela ne soit pas ce script qui soit exécuté, il faudrait encore vérifier cela, p.ex. avec systemctl status gwsetup.service P.ex. chez moi avec bind9: /lib/systemd/system/bind9.service qui exécute ExecStart=/usr/sbin/named -f $OPTIONS (et donc ignore superbement tout changement à /etc/init.d/bind9, qui n'est là que pour la compatibilité). Vous pourriez modifier le script init de gwsetup, en supposant que c'est le bon, pour: log_begin_msg "Starting gwsetup server" "gwsetup" if ! start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER; then log_end_msg 1 exit 1 fi ajouter un "echo" du genre echo start-stop-daemon -b --start --quiet --chuid $GENEWEBUSER --exec $WRAPPER et vous aurez les arguments complets (mais peut-être pas certaines variables d'environnement). Et éventuellement consulter le script $WRAPPER pour voir comment il lance. Puis ajouter les arguments de debugging nécessaires.
Geo Cherchetout
Le 12/04/2019 18:39, *Marc SCHAEFER* a écrit :
Faites-voir plutôt un - reboot de votre pi - vérification avec ps auxw | grep gwsetup qu'il n'est pas lancé - systemctl gwsetup stop - systemctl gwsetup start ensuite regardez s'il est lancé, puis consultez à nouveau les logs (ls -lart /var/log # t pour sort-by-time) et le journalctl -xe. systemctl restart fait un stop ce qui pollue les logs, à voir.
Problème résolu. J'ai constaté que gwsetup a besoin pour démarrer de trouver un fichier /var/log/gwsetup.log et peut-être aussi geneweb.log, or ces fichiers disparaissent chaque fois que je re-boote la bestiole depuis que j'ai mis cette ligne dans /etc/fstab : tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0 Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-) Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés automatiquement au boot. Cron doit pouvoir faire ça. Merci pour le soutien et les petits trucs que je ne connaissais pas.
Le 12/04/2019 18:39, *Marc SCHAEFER* a écrit :
Faites-voir plutôt un
- reboot de votre pi
- vérification avec ps auxw | grep gwsetup
qu'il n'est pas lancé
- systemctl gwsetup stop
- systemctl gwsetup start
ensuite regardez s'il est lancé, puis consultez à nouveau
les logs (ls -lart /var/log # t pour sort-by-time) et
le journalctl -xe.
systemctl restart fait un stop ce qui pollue les logs,
à voir.
Problème résolu. J'ai constaté que gwsetup a besoin pour démarrer de trouver
un fichier /var/log/gwsetup.log et peut-être aussi geneweb.log, or ces
fichiers disparaissent chaque fois que je re-boote la bestiole depuis que
j'ai mis cette ligne dans /etc/fstab :
tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0
Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et
l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)
Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés
automatiquement au boot. Cron doit pouvoir faire ça.
Merci pour le soutien et les petits trucs que je ne connaissais pas.
Faites-voir plutôt un - reboot de votre pi - vérification avec ps auxw | grep gwsetup qu'il n'est pas lancé - systemctl gwsetup stop - systemctl gwsetup start ensuite regardez s'il est lancé, puis consultez à nouveau les logs (ls -lart /var/log # t pour sort-by-time) et le journalctl -xe. systemctl restart fait un stop ce qui pollue les logs, à voir.
Problème résolu. J'ai constaté que gwsetup a besoin pour démarrer de trouver un fichier /var/log/gwsetup.log et peut-être aussi geneweb.log, or ces fichiers disparaissent chaque fois que je re-boote la bestiole depuis que j'ai mis cette ligne dans /etc/fstab : tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0 Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-) Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés automatiquement au boot. Cron doit pouvoir faire ça. Merci pour le soutien et les petits trucs que je ne connaissais pas.
Marc SCHAEFER
Geo Cherchetout wrote:
j'ai mis cette ligne dans /etc/fstab : tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0
Ah oui, donc /var/log est perdu à chaque redémarrage, ennuyeux.
Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé par systemd) pour créer ces répertoires et fichiers avec les bons droits avant de lancer.
Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés automatiquement au boot. Cron doit pouvoir faire ça.
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup
tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0
Ah oui, donc /var/log est perdu à chaque redémarrage, ennuyeux.
Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et
l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé
par systemd) pour créer ces répertoires et fichiers avec les bons droits
avant de lancer.
Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés
automatiquement au boot. Cron doit pouvoir faire ça.
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local
for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done
j'ai mis cette ligne dans /etc/fstab : tmpfs /var/log tmpfs defaults,noatime,nosuid,mode55,size m 0 0
Ah oui, donc /var/log est perdu à chaque redémarrage, ennuyeux.
Il y a 5 minutes j'ai recréé manuellement les dits fichiers de log et l'utilisateur pi a réussi du premier coup à faire un restart effectif. :-)
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé par systemd) pour créer ces répertoires et fichiers avec les bons droits avant de lancer.
Je n'ai plus qu'à faire en sorte que gwsetup.log et geneweb.log soit recréés automatiquement au boot. Cron doit pouvoir faire ça.
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup
Geo Cherchetout
Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé par systemd) pour créer ces répertoires et fichiers avec les bons droits avant de lancer.
Je viens enfin de découvrir /usr/lib/geneweb/gwsetup.wrapper. Voici ce qu'il contient : $ sudo cat /usr/lib/geneweb/gwsetup.wrapper #!/bin/sh # This is a wrapper script for starting gwsetup from the init script # It is needed for properly set up the umask the daemon runs under # as start-stop-daemon does not allow this and have the program # run with /var/lib/geneweb as default directory so that created bases # go there umask 007 cd $GENEWEBDB # Use a non predictable name for the temporary command output file TEMPFILE=`tempfile` $DAEMON -gd $GENEWEBSHARE -lang $LNG -p $GWSETUP_PORT -bindir /usr/bin -only $GWSETUPONLYFILE -log $TEMPFILE -daemon >>/var/log/gwsetup.log 2>&1 exit $? Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé lors de la prochaine mise à jour du programme ?
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup
Ça me plait bien, ça, merci beaucoup, je vais essayer de le mettre en place.
Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé
par systemd) pour créer ces répertoires et fichiers avec les bons droits
avant de lancer.
Je viens enfin de découvrir /usr/lib/geneweb/gwsetup.wrapper. Voici ce qu'il
contient :
$ sudo cat /usr/lib/geneweb/gwsetup.wrapper
#!/bin/sh
# This is a wrapper script for starting gwsetup from the init script
# It is needed for properly set up the umask the daemon runs under
# as start-stop-daemon does not allow this and have the program
# run with /var/lib/geneweb as default directory so that created bases
# go there
umask 007
cd $GENEWEBDB
# Use a non predictable name for the temporary command output file
TEMPFILE=`tempfile`
$DAEMON -gd $GENEWEBSHARE -lang $LNG -p $GWSETUP_PORT -bindir /usr/bin -only
$GWSETUPONLYFILE -log $TEMPFILE -daemon >>/var/log/gwsetup.log 2>&1
exit $?
Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé
lors de la prochaine mise à jour du programme ?
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local
for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done
systemctl start gwsetup
Ça me plait bien, ça, merci beaucoup, je vais essayer de le mettre en place.
Modifier le vrai script de démarrage de gwsetup (celui qui est référencé par systemd) pour créer ces répertoires et fichiers avec les bons droits avant de lancer.
Je viens enfin de découvrir /usr/lib/geneweb/gwsetup.wrapper. Voici ce qu'il contient : $ sudo cat /usr/lib/geneweb/gwsetup.wrapper #!/bin/sh # This is a wrapper script for starting gwsetup from the init script # It is needed for properly set up the umask the daemon runs under # as start-stop-daemon does not allow this and have the program # run with /var/lib/geneweb as default directory so that created bases # go there umask 007 cd $GENEWEBDB # Use a non predictable name for the temporary command output file TEMPFILE=`tempfile` $DAEMON -gd $GENEWEBSHARE -lang $LNG -p $GWSETUP_PORT -bindir /usr/bin -only $GWSETUPONLYFILE -log $TEMPFILE -daemon >>/var/log/gwsetup.log 2>&1 exit $? Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé lors de la prochaine mise à jour du programme ?
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup
Ça me plait bien, ça, merci beaucoup, je vais essayer de le mettre en place.
Marc SCHAEFER
Geo Cherchetout wrote:
Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé lors de la prochaine mise à jour du programme ?
Chaque package Debian (et donc vraisemblablement raspbian) peut enregistrer des fichiers de configuration dont les modifications sont gérées aux mises à jour. Par exemple, si toi ou un script a modifié un de ces fichiers, la mise à jour te proposera un dialogue pour corriger le problème. On peut lister les fichiers de config ainsi (exemple pour xfig: :/home/schaefer# cat /var/lib/dpkg/info/xfig.conffiles /etc/X11/app-defaults/Fig /etc/X11/ja_JP.eucJP/app-defaults/Fig /etc/X11/ko_KR.eucKR/app-defaults/Fig ) Toutefois, effectivement, tout autre fichier d'un package (exécutable, script, etc) sera écrasé sans vérification. Mais Debian propose une deuxième solution: les diversions. Par exemple, dans mon cas je veux que /usr/bin/soffice soit en fait remplacé par un wrapper-script de mon cru, alors j'ai installé une diversion de /usr/bin/soffice à /usr/bin/soffice.distrib et créé mon propre script (ou exécutable, ou symlink) dans /usr/bin/soffice donc les mises à jour de la distribution du package contenant ce fichier sont maintenant faites dans le fichier qui se termine par .distrib et plus mon wrapper-script. Voir `man dpkg-divert' Attention toutefois, si tu utilises des diversions, de bien vérifier (par diff p.ex.) à chaque mise à jour, en particulier de version de la distribution, que d'éventuels patches de sécurité ne sont pas à porter à ta version de fichier. Cf man dpkg-divert
Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé
lors de la prochaine mise à jour du programme ?
Chaque package Debian (et donc vraisemblablement raspbian) peut enregistrer
des fichiers de configuration dont les modifications sont gérées aux mises à
jour. Par exemple, si toi ou un script a modifié un de ces fichiers, la mise
à jour te proposera un dialogue pour corriger le problème. On peut lister les
fichiers de config ainsi (exemple pour xfig:
root@reliand:/home/schaefer# cat /var/lib/dpkg/info/xfig.conffiles
/etc/X11/app-defaults/Fig
/etc/X11/ja_JP.eucJP/app-defaults/Fig
/etc/X11/ko_KR.eucKR/app-defaults/Fig
)
Toutefois, effectivement, tout autre fichier d'un package (exécutable,
script, etc) sera écrasé sans vérification.
Mais Debian propose une deuxième solution: les diversions. Par exemple,
dans mon cas je veux que /usr/bin/soffice soit en fait remplacé par
un wrapper-script de mon cru, alors j'ai installé une diversion
de /usr/bin/soffice à /usr/bin/soffice.distrib et créé mon propre
script (ou exécutable, ou symlink) dans /usr/bin/soffice donc les
mises à jour de la distribution du package contenant ce fichier
sont maintenant faites dans le fichier qui se termine par .distrib
et plus mon wrapper-script. Voir `man dpkg-divert'
Attention toutefois, si tu utilises des diversions, de bien vérifier (par
diff p.ex.) à chaque mise à jour, en particulier de version de la distribution,
que d'éventuels patches de sécurité ne sont pas à porter à ta version de
fichier. Cf man dpkg-divert
Supposons que je parvienne à modifier ce wrapper, ne sera-t-il pas écrasé lors de la prochaine mise à jour du programme ?
Chaque package Debian (et donc vraisemblablement raspbian) peut enregistrer des fichiers de configuration dont les modifications sont gérées aux mises à jour. Par exemple, si toi ou un script a modifié un de ces fichiers, la mise à jour te proposera un dialogue pour corriger le problème. On peut lister les fichiers de config ainsi (exemple pour xfig: :/home/schaefer# cat /var/lib/dpkg/info/xfig.conffiles /etc/X11/app-defaults/Fig /etc/X11/ja_JP.eucJP/app-defaults/Fig /etc/X11/ko_KR.eucKR/app-defaults/Fig ) Toutefois, effectivement, tout autre fichier d'un package (exécutable, script, etc) sera écrasé sans vérification. Mais Debian propose une deuxième solution: les diversions. Par exemple, dans mon cas je veux que /usr/bin/soffice soit en fait remplacé par un wrapper-script de mon cru, alors j'ai installé une diversion de /usr/bin/soffice à /usr/bin/soffice.distrib et créé mon propre script (ou exécutable, ou symlink) dans /usr/bin/soffice donc les mises à jour de la distribution du package contenant ce fichier sont maintenant faites dans le fichier qui se termine par .distrib et plus mon wrapper-script. Voir `man dpkg-divert' Attention toutefois, si tu utilises des diversions, de bien vérifier (par diff p.ex.) à chaque mise à jour, en particulier de version de la distribution, que d'éventuels patches de sécurité ne sont pas à porter à ta version de fichier. Cf man dpkg-divert
Geo Cherchetout
Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup
Essayé et approuvé, merci beaucoup. :-)
Le 13/04/2019 08:58, *Marc SCHAEFER* a écrit :
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère
/etc/rc.local
for i in gwsetup geneweb
do
touch /var/log/$i.log
# évt. chown ?
done
Oui, avec le @reboot dans une crontab user, mais pour le système je préfère /etc/rc.local for i in gwsetup geneweb do touch /var/log/$i.log # évt. chown ? done systemctl start gwsetup