rc.init, systemd et etc

JKB

22/10/2016 à 23:42

Le Fri, 21 Oct 2016 18:45:08 +0200,
Eric Stern écrivait :

JKB wrote:
Le Fri, 21 Oct 2016 01:19:24 +0200,
Eric Stern écrivait :
le problème ne serait pas pas plutôt support ? Suse et Redhat le font eu
même si contrat.pour Debian ou autre, c'est le prestataire.

Lorsqu'un serveur est en rade, je me contrefiche du support. Ce qui
est hébergé ne fonctionne plus.

Je peux me tromper mais j'ai l'impression que ton travail est dans le
développent logiciel/hardware d'après ce que je lis ailleurs.

Très certes.

Quand tu parles de serveur en rade, ce sont les tiens, ceux de tes clients
que tu administres ou c'est ceux que tu utilises pour tes taches
d'intégrations ?

Les miens qui hébergent accessoirement des bases de clients.

et sur quelle distri ?

Il y a eu du Redhat, viré pour Debian. Il y a eu des tentatives avec
Ubuntu et Centos et mes Linux restent maintenant sur Debian. Il y en
a de moins en moins, je les remplace dès que je peux par des BSD,
principalement Free et Net. Beaucoup moins d'emmerdes.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Kevin Denis

24/10/2016 à 15:43

Le 19-10-2016, Eric Stern a écrit :

En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac
Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.
Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:
:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
:~$
(286 lignes! )
:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
:~$
(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)
Jetons un oeil, et essayons de voir comment apache démarre, on grep[1] un
coup:
case $1 in
start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;
okay. log_daemon_msg, c'est quoi?
:~$ man log_daemon_msg
Aucune entrée de manuel pour log_daemon_msg
:~$
Bon, il y a des include dans le script? au début, histoire que ce soit
lisible? Non, ça commence comme ça:
set -e
SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
else
DIR_SUFFIX fi
elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
else
DIR_SUFFIX APACHE_CONFDIR=/etc/apache2
fi
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi
export APACHE_CONFDIR APACHE_ENVVARS
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
Et bien alors on fouille. On fouille, et puis ligne 60:
59
60 . /lib/lsb/init-functions
61
Bravo. On balance des fonctions non documentées dans un script, et
son script d'include est à la ligne *60* ?! WTF?
Allons le lire. Il contient des informations importantes comme:
# On Debian, would output "Starting remote filesystem services:"
# On Ubuntu, would output " * Starting remote filesystem services..."
ou
# #319739
#
Ca, j'adore:
# Pre&Post empty function declaration, to be overriden from /lib/lsb/init-fu nctions.d/*
on a une partie du script qui ne fait rien, juste pour être sûr que ce
soit fait ailleurs.
Bon, on finit par aller lire log_daemon_msg:
log_daemon_msg () {
if [ -z "${1:-}" ]; then
return 1
fi
log_daemon_msg_pre "$@"
if [ -z "${2:-}" ]; then
/bin/echo -n "$1:" || true
return
fi
/bin/echo -n "$1: $2" || true
log_daemon_msg_post "$@"
}
SRSLY? Bon, laisson tomber là, car on sinon on va continuer pendant 6 mois
à traquer les fonctions qui s'appellent entre elles.
Reprenons le cours de notre script, on a pas bien vu ce qui se passe ensuite:
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
Là, c'est mieux, c'est défini ligne 82:
APACHE2CTL="$ENV /usr/sbin/apache2ctl"
Je laisse tomber check_htclean. Dans le même genre d'amusement, toujours
dans le même script, nous avons:
#edit /etc/default/apache2 to change this.
HTCACHECLEAN_RUN=auto
HTCACHECLEAN_MODEÚemon
HTCACHECLEAN_SIZE00M
HTCACHECLEAN_DAEMON_INTERVAL0
HTCACHECLEAN_PATH=/var/cache/apache2$DIR_SUFFIX/mod_disk_cache
HTCACHECLEAN_OPTIONS=""
Grandiose. On définit des trucs là, mais faut les modifier ailleurs.
Merci, sympa D..N o/
Ca c'est que j'appelle le plat de spaghettis immangeable.
Et sur distrib avec du systemd, que j'appelerai --BIA- pour respecter
son droit à la vie privée, je ne peux pas aller voir apache2 (c'est encore
du sysV), mais si on regarde ssh:
:/lib/systemd/system$ ls -l /etc/systemd/system/sshd.service
lrwxrwxrwx 1 root root 31 sept. 3 2014 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
:/lib/systemd/system$ cat /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=sshd.service
:/lib/systemd/system$
Bon, allez trouver les options de ces scripts (SSHD_OPTS? MAINPID?) le
pourquoi du fichier sshd_not_to_be_run ça reste aussi fantastique.
hint: ça commence par:
:/lib/systemd/system$ man sshd | grep sshd_not_to_be_run
:/lib/systemd/system$

Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.

Voui voui voui. Ils prennent une distro lambda, freezent les packages,
se débrouillent pour compiler leur soft et ne font plus aucune mise à
jour.
[1] Je préfère une grep suzette, mais bon.
--
Kevin

Le 19-10-2016, Eric Stern <xdv5@coulommiers.org> a écrit :

En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac

Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.

Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:

kdenis@kdenis:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
kdenis@kdenis:~$

(286 lignes! )

kdenis@kdenis:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
kdenis@kdenis:~$

(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)

Jetons un oeil, et essayons de voir comment apache démarre, on grep[1] un
coup:
case $1 in
start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;

okay. log_daemon_msg, c'est quoi?
kdenis@kdenis:~$ man log_daemon_msg
Aucune entrée de manuel pour log_daemon_msg
kdenis@kdenis:~$

Bon, il y a des include dans le script? au début, histoire que ce soit
lisible? Non, ça commence comme ça:
set -e

SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
else
DIR_SUFFIX fi
elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
else
DIR_SUFFIX APACHE_CONFDIR=/etc/apache2
fi
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi
export APACHE_CONFDIR APACHE_ENVVARS

ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"

Et bien alors on fouille. On fouille, et puis ligne 60:
59
60 . /lib/lsb/init-functions
61

Bravo. On balance des fonctions non documentées dans un script, et
son script d'include est à la ligne *60* ?! WTF?

Allons le lire. Il contient des informations importantes comme:
# On Debian, would output "Starting remote filesystem services:"
# On Ubuntu, would output " * Starting remote filesystem services..."

ou
# #319739
#

Ca, j'adore:
# Pre&Post empty function declaration, to be overriden from /lib/lsb/init-fu nctions.d/*

on a une partie du script qui ne fait rien, juste pour être sûr que ce
soit fait ailleurs.

Bon, on finit par aller lire log_daemon_msg:
log_daemon_msg () {
if [ -z "${1:-}" ]; then
return 1
fi
log_daemon_msg_pre "$@"

if [ -z "${2:-}" ]; then
/bin/echo -n "$1:" || true
return
fi

/bin/echo -n "$1: $2" || true
log_daemon_msg_post "$@"
}

SRSLY? Bon, laisson tomber là, car on sinon on va continuer pendant 6 mois
à traquer les fonctions qui s'appellent entre elles.

Reprenons le cours de notre script, on a pas bien vu ce qui se passe ensuite:
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1

Là, c'est mieux, c'est défini ligne 82:
APACHE2CTL="$ENV /usr/sbin/apache2ctl"

Je laisse tomber check_htclean. Dans le même genre d'amusement, toujours
dans le même script, nous avons:
#edit /etc/default/apache2 to change this.
HTCACHECLEAN_RUN=auto
HTCACHECLEAN_MODEÚemon
HTCACHECLEAN_SIZE00M
HTCACHECLEAN_DAEMON_INTERVAL0
HTCACHECLEAN_PATH=/var/cache/apache2$DIR_SUFFIX/mod_disk_cache
HTCACHECLEAN_OPTIONS=""

Grandiose. On définit des trucs là, mais faut les modifier ailleurs.
Merci, sympa D..N o/

Ca c'est que j'appelle le plat de spaghettis immangeable.

Et sur distrib avec du systemd, que j'appelerai --BIA- pour respecter
son droit à la vie privée, je ne peux pas aller voir apache2 (c'est encore
du sysV), mais si on regarde ssh:
kevin@deb8:/lib/systemd/system$ ls -l /etc/systemd/system/sshd.service
lrwxrwxrwx 1 root root 31 sept. 3 2014 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
kevin@deb8:/lib/systemd/system$ cat /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service
kevin@deb8:/lib/systemd/system$

Bon, allez trouver les options de ces scripts (SSHD_OPTS? MAINPID?) le
pourquoi du fichier sshd_not_to_be_run ça reste aussi fantastique.

hint: ça commence par:
kevin@deb8:/lib/systemd/system$ man sshd | grep sshd_not_to_be_run
kevin@deb8:/lib/systemd/system$

Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.

Voui voui voui. Ils prennent une distro lambda, freezent les packages,
se débrouillent pour compiler leur soft et ne font plus aucune mise à
jour.

[1] Je préfère une grep suzette, mais bon.
--
Kevin

Vous avez filtré cet utilisateur ! Consultez son message

Le 19-10-2016, Eric Stern a écrit :

En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac
Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.
Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:
:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
:~$
(286 lignes! )
:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
:~$
(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)
Jetons un oeil, et essayons de voir comment apache démarre, on grep[1] un
coup:
case $1 in
start)
log_daemon_msg "Starting web server" "apache2"
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;
okay. log_daemon_msg, c'est quoi?
:~$ man log_daemon_msg
Aucune entrée de manuel pour log_daemon_msg
:~$
Bon, il y a des include dans le script? au début, histoire que ce soit
lisible? Non, ça commence comme ça:
set -e
SCRIPTNAME="${0##*/}"
SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then
if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
else
DIR_SUFFIX fi
elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
else
DIR_SUFFIX APACHE_CONFDIR=/etc/apache2
fi
if [ -z "$APACHE_ENVVARS" ] ; then
APACHE_ENVVARS=$APACHE_CONFDIR/envvars
fi
export APACHE_CONFDIR APACHE_ENVVARS
ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
Et bien alors on fouille. On fouille, et puis ligne 60:
59
60 . /lib/lsb/init-functions
61
Bravo. On balance des fonctions non documentées dans un script, et
son script d'include est à la ligne *60* ?! WTF?
Allons le lire. Il contient des informations importantes comme:
# On Debian, would output "Starting remote filesystem services:"
# On Ubuntu, would output " * Starting remote filesystem services..."
ou
# #319739
#
Ca, j'adore:
# Pre&Post empty function declaration, to be overriden from /lib/lsb/init-fu nctions.d/*
on a une partie du script qui ne fait rien, juste pour être sûr que ce
soit fait ailleurs.
Bon, on finit par aller lire log_daemon_msg:
log_daemon_msg () {
if [ -z "${1:-}" ]; then
return 1
fi
log_daemon_msg_pre "$@"
if [ -z "${2:-}" ]; then
/bin/echo -n "$1:" || true
return
fi
/bin/echo -n "$1: $2" || true
log_daemon_msg_post "$@"
}
SRSLY? Bon, laisson tomber là, car on sinon on va continuer pendant 6 mois
à traquer les fonctions qui s'appellent entre elles.
Reprenons le cours de notre script, on a pas bien vu ce qui se passe ensuite:
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
Là, c'est mieux, c'est défini ligne 82:
APACHE2CTL="$ENV /usr/sbin/apache2ctl"
Je laisse tomber check_htclean. Dans le même genre d'amusement, toujours
dans le même script, nous avons:
#edit /etc/default/apache2 to change this.
HTCACHECLEAN_RUN=auto
HTCACHECLEAN_MODEÚemon
HTCACHECLEAN_SIZE00M
HTCACHECLEAN_DAEMON_INTERVAL0
HTCACHECLEAN_PATH=/var/cache/apache2$DIR_SUFFIX/mod_disk_cache
HTCACHECLEAN_OPTIONS=""
Grandiose. On définit des trucs là, mais faut les modifier ailleurs.
Merci, sympa D..N o/
Ca c'est que j'appelle le plat de spaghettis immangeable.
Et sur distrib avec du systemd, que j'appelerai --BIA- pour respecter
son droit à la vie privée, je ne peux pas aller voir apache2 (c'est encore
du sysV), mais si on regarde ssh:
:/lib/systemd/system$ ls -l /etc/systemd/system/sshd.service
lrwxrwxrwx 1 root root 31 sept. 3 2014 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
:/lib/systemd/system$ cat /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=sshd.service
:/lib/systemd/system$
Bon, allez trouver les options de ces scripts (SSHD_OPTS? MAINPID?) le
pourquoi du fichier sshd_not_to_be_run ça reste aussi fantastique.
hint: ça commence par:
:/lib/systemd/system$ man sshd | grep sshd_not_to_be_run
:/lib/systemd/system$

Tout ces joyeux industriels ont eu besoin de quelque chose de standardisé,
de pratique et de pas trop "dinosaurien" pour assurer une réussite de chaque
mise à jour ou adjonction de fonctionnalité.

Voui voui voui. Ils prennent une distro lambda, freezent les packages,
se débrouillent pour compiler leur soft et ne font plus aucune mise à
jour.
[1] Je préfère une grep suzette, mais bon.
--
Kevin

JKB

24/10/2016 à 15:50

Le 24 Oct 2016 13:43:05 GMT,
Kevin Denis écrivait :

Le 19-10-2016, Eric Stern a écrit :
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac
Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.
Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:
:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
:~$
(286 lignes! )
:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
:~$
(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)

Très certes, cher. Mai sdans le cas de D....N, en SysV, tu savais
qu'il était possible de surcharger les variables des scripts init
dans /etc/default. Et s'il fallait une valeur différente pour une
seule variable, tu ne touchais qu'à celle-là.
Avec systemd, c'est largement rigologène. Parce que tu ne surcharges
pas une variable. Tu es contraint de surcharger l'ensemble du
fichier de description du daemon. En cas de mise à jour, ça peut
assez rapidement devenir casse-gueule.
Mais bon, systemd, c'est le bien, l'avenir.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 24 Oct 2016 13:43:05 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :

Le 19-10-2016, Eric Stern <xdv5@coulommiers.org> a écrit :

En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac

Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.

Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:

kdenis@kdenis:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
kdenis@kdenis:~$

(286 lignes! )

kdenis@kdenis:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
kdenis@kdenis:~$

(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)

Très certes, cher. Mai sdans le cas de D....N, en SysV, tu savais
qu'il était possible de surcharger les variables des scripts init
dans /etc/default. Et s'il fallait une valeur différente pour une
seule variable, tu ne touchais qu'à celle-là.

Avec systemd, c'est largement rigologène. Parce que tu ne surcharges
pas une variable. Tu es contraint de surcharger l'ensemble du
fichier de description du daemon. En cas de mise à jour, ça peut
assez rapidement devenir casse-gueule.

Mais bon, systemd, c'est le bien, l'avenir.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le 24 Oct 2016 13:43:05 GMT,
Kevin Denis écrivait :

Le 19-10-2016, Eric Stern a écrit :
En lisant en diagonale, j'ai lu ou cru avoir lu que des intervenants
considéraient le principe des liens symboliques comme un paquet de
spaghetti, quelque chose d'inutilisable.

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac
Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.
Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:
:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
:~$
(286 lignes! )
:~$ /etc/init.d/apache2 help
[....] Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force[ ok ad|start-htcacheclean|stop-htcacheclean|status}.
:~$
(oui, la sortie est comme ça, moche, avec le ok qui déborde sur une commande)

Très certes, cher. Mai sdans le cas de D....N, en SysV, tu savais
qu'il était possible de surcharger les variables des scripts init
dans /etc/default. Et s'il fallait une valeur différente pour une
seule variable, tu ne touchais qu'à celle-là.
Avec systemd, c'est largement rigologène. Parce que tu ne surcharges
pas une variable. Tu es contraint de surcharger l'ensemble du
fichier de description du daemon. En cas de mise à jour, ça peut
assez rapidement devenir casse-gueule.
Mais bon, systemd, c'est le bien, l'avenir.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Doug713705

25/10/2016 à 08:10

Le 24-10-2016, Kevin Denis nous expliquait dans
fr.comp.os.linux.debats
() :

Voilà un script (complet, hors commentaires) de démarrage d'apache:
case "$1" in
'start')
/usr/sbin/apachectl -k start
;;
'stop')
/usr/sbin/apachectl -k stop
killall httpd
rm -f /var/run/httpd/*.pid
;;
'restart')
/usr/sbin/apachectl -k restart
;;
'graceful')
/usr/sbin/apachectl -k graceful
;;
'graceful-stop')
/usr/sbin/apachectl -k graceful-stop
;;
*)
echo "Usage: $0 {start|stop|restart|graceful|graceful-stop}"
;;
esac
Posons nous la question: que se passe t'il lorsque je démarre apache?
La réponse devrait prendre à peu près moins d'une demie seconde chez
toute personne munie d'un cerveau, sauf certains qui vont trouver moyen à
critiquer bêtement. Laissons les, et passons à autre chose.
Tentons la même chose sur une autre distrib, que nous appellerons
D..N afin de ne pas compromettre sa vie privée:
:~$ wc -l /etc/init.d/apache2
286 /etc/init.d/apache2
:~$
(286 lignes! )

[SNIP le démélage de spaghettis]

SRSLY? Bon, laisson tomber là, car on sinon on va continuer pendant 6 mois
à traquer les fonctions qui s'appellent entre elles.

Ça s'appelle créer le besoin.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43

Nicolas George

25/10/2016 à 11:17

JKB , dans le message , a
écrit :

Avec systemd, c'est largement rigologène. Parce que tu ne surcharges
pas une variable. Tu es contraint de surcharger l'ensemble du
fichier de description du daemon.

Voilà encore une preuve supplémentaire : les détracteurs les plus virulents
de systemd déversent leur haine sans savoir réellement de quoi ils parlent :
https://wiki.archlinux.org/index.php/Systemd#Drop-in_files
(La doc officielle serait :
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
mais comme elle est rédigée comme une page de man, pas possible de faire un
lien interne.)

Nicolas George

25/10/2016 à 11:18

Doug713705 , dans le message <numt0o$rog$, a
écrit :

Ça s'appelle créer le besoin.

Tu peux préciser ta pensée ? Tu n'es pas en train de suggérer que les
différentes distributions ont transformé leurs scripts d'init en spaghettis
exprès pour paver la voie pour systemd, par hasard ?

remy

25/10/2016 à 15:28

Le 20/10/2016 14:54, Nicolas George a Ã©crit :

Michel Talon , dans le message <5808b7c4$0$7125$,
a Ã©crit :
Pourtant l'objection de la pieuvre est absolument Ã©vidente.

En effet, la mauvaise foi est absolument Ã©vidente.
A partir du
moment oÃ¹ un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât hav e time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche Ã faire tout ce qu'il
ne faut pas faire, et d'une dÃ©pendance Ã systemd indirecte, v ia logind, qui
est optionnel.

tien le retour des vieux con(prÃ©sent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redÃ©marrage automatique si le
daemon tombe
remy
--
http://remyaumeunier.chez-alice.fr/

JKB

25/10/2016 à 15:48

Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :

Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.

En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

remy

25/10/2016 à 16:37

Le Tue, 25 Oct 2016 15:28:58 +0200,
remy Ã©crivait :
Le 20/10/2016 14:54, Nicolas George a Ã©crit :
Michel Talon , dans le message <5808b7c4$0$7125$ >,
a Ã©crit :
Pourtant l'objection de la pieuvre est absolument Ã©vidente.

En effet, la mauvaise foi est absolument Ã©vidente.
A partir du
moment oÃ¹ un certain nombre de logiciels d'usage courant (exemp le Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât h ave time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of suppo rt
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid a ny
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche Ã faire tou t ce qu'il
ne faut pas faire, et d'une dÃ©pendance Ã systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(prÃ©sent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redÃ©marrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas Ã redÃ©marrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrÃ´lent la bonne
exÃ©cution des daemons avec des crons, mais je trouve Ã§a comp lÃ¨tement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problÃ¨me en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

il existe Strace mais les log sont imbitable comme dab dâailleurs
dÃ©soler mais la plupart du temps ont prÃ©fÃ¨re attendre la v ersion
suivante du bouzin pas stable mais indispensable
et donc ma question reste entiÃ¨re
remy
--
http://remyaumeunier.chez-alice.fr/

Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> Ã©crivait :

Le 20/10/2016 14:54, Nicolas George a Ã©crit :

Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.free.fr >,
a Ã©crit :

Pourtant l'objection de la pieuvre est absolument Ã©vidente.

En effet, la mauvaise foi est absolument Ã©vidente.

A partir du
moment oÃ¹ un certain nombre de logiciels d'usage courant (exemp le Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they donât h ave time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of suppo rt
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid a ny
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche Ã faire tou t ce qu'il
ne faut pas faire, et d'une dÃ©pendance Ã systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(prÃ©sent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redÃ©marrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas Ã redÃ©marrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.

Sinon, je connais des petits rigolos qui contrÃ´lent la bonne
exÃ©cution des daemons avec des crons, mais je trouve Ã§a comp lÃ¨tement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problÃ¨me en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

il existe Strace mais les log sont imbitable comme dab dâailleurs
dÃ©soler mais la plupart du temps ont prÃ©fÃ¨re attendre la v ersion
suivante du bouzin pas stable mais indispensable
et donc ma question reste entiÃ¨re

remy

--
http://remyaumeunier.chez-alice.fr/

JKB

25/10/2016 à 16:48

Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :

Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.

En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière

Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le Tue, 25 Oct 2016 16:37:14 +0200,
remy <remy@fctpas.fr> écrivait :

Le 25/10/2016 15:48, JKB a écrit :

Le Tue, 25 Oct 2016 15:28:58 +0200,
remy <remy@fctpas.fr> écrivait :

Le 20/10/2016 14:54, Nicolas George a écrit :

Michel Talon , dans le message <5808b7c4$0$7125$426a34cc@news.free.fr>,
a écrit :

Pourtant l'objection de la pieuvre est absolument évidente.

En effet, la mauvaise foi est absolument évidente.

A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.

Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière

Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Vous avez filtré cet utilisateur ! Consultez son message

Le Tue, 25 Oct 2016 16:37:14 +0200,
remy écrivait :

Le 25/10/2016 15:48, JKB a écrit :
Le Tue, 25 Oct 2016 15:28:58 +0200,
remy écrivait :
Le 20/10/2016 14:54, Nicolas George a écrit :
Michel Talon , dans le message <5808b7c4$0$7125$,
a écrit :
Pourtant l'objection de la pieuvre est absolument évidente.

En effet, la mauvaise foi est absolument évidente.
A partir du
moment où un certain nombre de logiciels d'usage courant (exemple Gnome)
demandent systemd, par exemple au sujet de Gentoo:
"
Due to 1) logind now requiring systemd, 2) that they don’t have time to
develop missing functionality in OpenRC 3) supporting non-systemd +
systemd at the same time likely resulting in bugs and a lot of support
time, they decided it is much easier to just require systemd/logind.
This also get the features that systemd and logind offer and avoid any
weird bugs (as most GNOME developers seem to use systemd).

Donc on parle de GNOME, une grosse bouze qui cherche à faire tout ce qu'il
ne faut pas faire, et d'une dépendance à systemd indirecte, via logind, qui
est optionnel.

tien le retour des vieux con(présent)
tu peux m'explique comme tu monitoring de manier automatique
un daemon avec rc.init un truc du style redémarrage automatique si le
daemon tombe

Un daemon qui explose en vol n'a pas à redémarrer tout seul. C'est
un dysfonctionnement qu'il faut traiter.
Sinon, je connais des petits rigolos qui contrôlent la bonne
exécution des daemons avec des crons, mais je trouve ça complètement
idiot. La solution est de trouver pourquoi il explose et de corriger
le problème en amont. Mais pour cela, il faut rester dans la
philosophie KISS.

il existe Strace mais les log sont imbitable comme dab d’ailleurs
désoler mais la plupart du temps ont préfère attendre la version
suivante du bouzin pas stable mais indispensable
et donc ma question reste entière

Et comme d'habitude, tu es en lecture seule. Je viens de t'expliquer
pourquoi ce n'est pas souhaitable.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

rc.init, systemd et etc

10 réponses

Veuillez sélectionner un problème