Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
$ head /etc/init/ssh.conf
description "SSH"
# started by group-mce.conf
stop on stopped dbus
console output
respawn
respawn limit 3 300
normal exit 0
oom -17
script
test -x /usr/sbin/sshd || exit 0
if test -f /etc/default/ssh; then
. /etc/default/ssh
fi
root_permitted="-o PermitRootLogin=no"
if test -x /usr/sbin/rdc_cert_verify && \
$(/usr/sbin/rdc_cert_verify &> /dev/null)
then
root_permitted="-o PermitRootLogin=yes"
fi
# Create the PrivSep empty dir if necessary
if [ ! -d /var/run/sshd ]; then
mkdir -p /var/run/sshd
chmod 0755 /var/run/sshd
fi
exec /usr/sbin/sshd $root_permitted $SSHD_OPTS
end script
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Je trouve ça bizarre pourquoi ne pas faire
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.