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

Re: Debian 8 bientôt publiée !



On 08/04/15 at 13:50 +0200, Francois Lafont wrote:
> 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 ?

Il y a une décision du comité technique de Debian qui dit, en août 2014:

  For the record, the TC expects maintainers to continue to support
  the multiple available init systems in Debian.  That includes
  merging reasonable contributions, and not reverting existing
  support without a compelling reason.

(https://lists.debian.org/debian-devel-announce/2014/08/msg00001.html)
 
- Lucas


Reply to: