[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian 8 bientôt publiée !



Bonjour,

Le 08/04/2015 08:48, Lucas Nussbaum a écrit :

>> Par exemple, au niveau des paquets qui installent un daemon (apache etc.
>> etc.), il faut bien que le postinst du paquet « active » le daemon, or
>> il me semble bien que les commandes ne sont pas les mêmes d'un système
>> init à l'autre. Comment ils font les développeurs de paquet pour que le
>> postinst marche quel que soit le système d'init mis en place sur l'OS ?
> 
> systemd a un "generator" qui cherche tous les scripts LSB (=~ SysV) qui
> n'ont pas de fichier service correspondant, en extrait diverses infos,
> et génère un fichier service pour systemd correspondant.
> 
> ces fichiers .service générés sont visibles dans
> /run/systemd/generator.late/, ou avec systemctl cat mon_service
> 
> Un exemple pour apache2 (on voit bien les appels au script dans
> /etc/init.d/ à la fin):
> -------------------------------------------------------->8
> # Automatically generated by systemd-sysv-generator
> 
> [Unit]
> SourcePath=/etc/init.d/apache2
> Description=LSB: Apache2 web server
> Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target
> After=local-fs.target remote-fs.target network-online.target systemd-journald-dev-log.socket nss-lookup.target
> Wants=network-online.target
> Conflicts=shutdown.target
> 
> [Service]
> Type=forking
> Restart=no
> TimeoutSec=5min
> IgnoreSIGPIPE=no
> KillMode=process
> GuessMainPID=no
> RemainAfterExit=yes
> SysVStartPriority=1
> ExecStart=/etc/init.d/apache2 start
> ExecStop=/etc/init.d/apache2 stop
> ExecReload=/etc/init.d/apache2 reload
> -------------------------------------------------------->8
> 
> La description du service est préfixée par "LSB:", ce qui permet de
> lister ces scripts avec "systemctl list-units | grep LSB:".

Ah ok, tout s'explique alors. En un mot, on peut dire en fait
que systemd assure une compatibilité avec SysV. Voilà qui a dû
soulager pas mal de développeurs de paquets (qui fournissent
un daemon).

>> De même, si un paquet a été développé et propose un joli script script
>> init pour System-V (ie un /etc/init.d/<le-deamon>), comment ils font
>> les développeurs du paquet pour leur paquet puisse aussi marcher avec
>> systemd ? Ils doivent se fendre aussi d'un fichier de conf pour que
>> systemd puisse aussi démarrer le daemon ? En gros les développeurs
>> doivent-ils fournir, pour chaque système d'init proposé par la distrib,
>> tout le nécessaire au niveau conf et/ou script de lancement etc. ?
> 
> Soit ils utilisent le mécanisme ci-dessus, soit ils fournissent un fichier
> .service. L'inconvénient avec les .service auto-générés, c'est que du coup, on
> passe à côté de certaines fonctionnalités de systemd. Par exemple, une des
> forces de systemd, c'est d'être capable de vraiment tuer tous les processus
> d'un service lors de l'arrêt, grâce au suivi avec les cgroups. Mais
> systemd-sysv-generator ne peut pas savoir si c'est une bonne idée de nettoyer
> un service particulier de cette manière (il y a des contre-exemples, comme
> sshd). Du coup, il utilise "KillMode=process", qui ne tue que le processus
> principal.

Merci beaucoup Lucas pour toutes des ces explications très intéressantes.
Mais j'ai encore une petite question du coup. ;)

Imaginons un développeur d'un paquet Debian fournissant un daemon. Supposons
que ce développeur soit très soucieux d'être « à la page ». Jusqu'à présent
il fournissait dans son paquet un script init sysV et du coup il se dit « zut
alors ! Faut que je fournisse un .service pour être dans les clous par rapport
à systemd ». Et supposons qu'il vire de son paquet, du coup, le script init.d
sysV. Alors dans ce cas, son paquet ne sera plus utilisable via sysV (qui
lui n'est pas compatible systemd), non ? Où alors la Debian policy lui « interdit »
peut-être tout simplement de supprimer le script init.d sysV de son paquet ?

-- 
François Lafont


Reply to: