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

Re: systemd et fichiers dans /etc/init.d/



steve a écrit :
> Le 30-01-2018, à 18:21:55 +0100, BERTRAND Joël a écrit :
> 
>> steve a écrit :
>>> Le 30-01-2018, à 15:08:21 +0100, BERTRAND Joël a écrit :
>>>
>>>
>>>>>> Ce qui permet d'ailleurs des effets de bord assez rigolos entre deux
>>>>>> versions de la chose.
>>>>>
>>>>> Du genre ? As-tu des exemples concrets ?
>>>>
>>>>     Des incohérences sur la gestion du réseau par exemple sur un
>>>> serveur
>>>> qui a deux taps, deux tuns, une interface bounding et cinq ethernet. En
>>>> fonction des versions de la bouse, ça démarre automatiquement ou non
>>>> (c'est le VPN qui merdoie à cause de son interaction avec iptables).
>>>
>>> Pourquoi avoir migré sur une configuration si complexe alors qu'il est
>>> possible de garder l'ancien système ?
>>
>>     Parce qu'il fallait bien que je me fasse une idée.
> 
> Tu aurais pu te la faire sur un système un peu moins complexe, non ?

	Bah non... Sur mon serveur de test avec une configuration simple, ça
fonctionnait. Ce n'est _que_ parce que la configuration était complexe
que systemd s'est baugé lamentablement comme la bouse qu'il est.

>>     Depuis, cette idée est faite, systemd est une calamité qui fonctionne
>> dans 98% des cas. SysV fonctionne quant à lui dans 100% des cas. Il faut
>> juste ne pas être dans les 2%.
> 
> Et tu peux vivre avec ce risque sur des machines de production ? Tes
> nuits doivent être mouvementées :)

	Merci, mes nuits sont généralement calmes.

>>>>>>     La seule chose qui peut à la rigueur être faite, c'est de
>>>>>> virer de
>>>>>> /etc/init.d ce qui est explicitement transcrit dans /lib/systemd
>>>>>> pour le
>>>>>> fonctionnement de l'usine à gaz avec des fuites.
>>>>>
>>>>> Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
>>>>> inutile.
>>>>>
>>>>>
>>>>>> PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
>>>>>> plus je rentre dedans, pire c'est.
>>>>>
>>>>> Rien à lui reprocher pour le moment pour un usage domestique.
>>>>     Il n'y a pas que l'usage domestique.
>>>
>>> Je sais, c'est pour cela que j'ai précisé.
>>>
>>>> Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
>>>> tout est déjà perdu) des serveurs à distance.
>>>
>>> Toujours chauds ce genre de manips, quelque soit le système.
>>
>>     Euh, non. Ça fait plus de 20 ans que j'ai des serveurs un peu
>> partout,
>> je n'ai peur de les redémarrer que lorsqu'ils utilisent systemd, surtout
>> après une mise à jour.
> 
> Je me rappelle avoir dû me déplacer à l'époque pour des serveurs qui ne
> répondaient plus après un redémarrage.

	Moi aussi. Mais là, je ne parle même pas du démarrage, mais de l'arrêt.
Par ailleurs, le système de boot de Linux est une vaste pantalonnade. Le
coup du initrd ou du ramfs, c'est vraiment grandiose, surtout depuis que
/etc/modules n'est pas exporté dans le ramfs. Un bricolage ! Il n'y a
aucune raison valable pour ne pas utiliser un système à la BSD.

>>>> Il y en a même qui ne s'arrêtent pas !
>>>
>>>
>>> M'est aussi arrivé avec l'ancien et obsolète système… Heureusement
>>> qu'il y avait une prise physique  ;)
>>
>>     Ça, j'aimerais bien savoir comment. Parce que SysV essaie d'arrêter
>> proprement les daemons. Il passe après un SIGTERM puis en dernier
>> ressort un SIGKILL. Si la machine ne s'arrêtait pas, ce n'était
>> certainement pas la faute d'init.
> 
> Peut-être, peut-être pas…

	Pour info, SIGKILL ne peut pas être récupéré par un programme. Donc
soit init est plant (jamais vu pour le SysV), soit le système est en
vrac (et ce n'est pas la faute d'init).

	JKB


Reply to: