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

Re: Debian 8 bientôt publiée !



On 08/04/15 at 10:00 +0200, Wallace wrote:
> 
> 
> Le 08/04/2015 08:48, Lucas Nussbaum a écrit :
> >
> > 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.
> >
> >
> > ExecStart=/etc/init.d/apache2 start
> > ExecStop=/etc/init.d/apache2 stop
> > ExecReload=/etc/init.d/apache2 reload
> Je n'avais pas regardé Apache car je l'utilise plus depuis des années,
> mais si les packages qui ne fournissent pas de configuration systemd, la
> gestion se transforme en dépendance au script init avec une surcouche au
> niveau systemd, aucun intérêt si ce n'est d'amener des problèmes à cours
> ou moyen terme.

C'est amusant de voir que d'un côté, tu te fais l'avocat de la
"philosophie Unix" consistant à combiner des outils indépendants (et
donc à empiler des couches), et de l'autre, tu argumentes que la
génération de fichiers service au-dessus des scripts LSB est de
l'empilage de couches qui va amener des problèmes.

> En gros on va avoir pendant un bon bout de temps une dépendance forte
> aux scripts init pour que systemd fonctionne...

On peut voir ça comme ça, ou voir ça comme un chemin de migration
relativement tranquille, permettant de mettre à jour les paquets
progressivement.

> Pour information, chez plusieurs éditeurs de progiciels dans le domaine
> médical, BI ou bancaire, j'ai déjà du mal à obtenir un script init
> fonctionnel, on est obligé de débugger avec eux et ils ne comprennent
> pas pourquoi on demande de tels scripts, eux lancent les daemons à la
> main ... Avec l'arrivée de systemd dans Debian 8 j'ai préparé le terrain
> en disant vous devrez nous fournir lors de la migration des systèmes
> vers la nouvelle Debian, la configuration du service pour systemd. La
> réponse de TOUS ces éditeurs FR ou étrangers, nous n'avons pas prévu de
> supporter systemd pire certains m'ont demandé ce que c'était alors que
> leur boite ne développe que pour Linux pour plusieurs distros.
> 
> C'est en tout cas un argument pour nous pour continuer à utiliser les
> scripts init standards car bien sur vis à vis du client final si cela ne
> marche pas ça sera de notre faute pas celle de l'éditeur. Passer du
> temps à faire la conversion de notre côté c'est potentiellement
> contourner le problème pour garder systemd mais c'est aussi s'assurer
> d'un non soutient des supports applicatifs au moindre problème, ils
> diront que la plateforme n'est pas valide.

Note qu'une force de systemd dans ce contexte est qu'écrire un fichier
service est beaucoup plus simple et rapide qu'écrire un script d'init,
vu qu'une grosse partie de la complexité est gérée par systemd au lieu
du script d'init. systemd simplifie aussi l'écriture des daemons,
puisqu'il n'y a plus besoin de forker, d'écrire des fichiers pid, de
gérer syslog, etc. (C'est lié à un des arguments des détracteurs de
systemd: "puisqu'il n'y a plus besoin de s'embeter avec ça, les daemons
vont arrêter de le faire, et ça ne marchera plus avec sysvinit").

Lucas


Reply to: