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).
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.
Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
tout est déjà perdu) des serveurs à distance.
Il y en a même qui ne s'arrêtent pas !
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).
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.
Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
tout est déjà perdu) des serveurs à distance.
Il y en a même qui ne s'arrêtent pas !
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).
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.
Depuis qu'on a systemd, j'en suis à ne plus redémarrer (sauf lorsque
tout est déjà perdu) des serveurs à distance.
Il y en a même qui ne s'arrêtent pas !
Salut Steve,
la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.
dpkg -S /etc/init.d/* | grep "no path"
Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.
Bonjour, j'ai regardé votre sujet en diagonale. J'ai lancé la commande,
mais, j'obtiens ce retour :
dpkg -S /etc/init.d/* | grep "no path"
dpkg-query: aucun chemin ne correspond à /etc/init.d/keyboard-setup.dpkg-bak
zsh: exit 1 dpkg -S /etc/init.d/* | grep "no path"
Noter que je ne suis pas sous Debian mais Mint.
Sous GNU/Linux Debian Stretch, et, mon serveur minimaliste, la commande
ne me retourne rien, sans message d'erreur.
Salut Steve,
la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.
dpkg -S /etc/init.d/* | grep "no path"
Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.
Bonjour, j'ai regardé votre sujet en diagonale. J'ai lancé la commande,
mais, j'obtiens ce retour :
dpkg -S /etc/init.d/* | grep "no path"
dpkg-query: aucun chemin ne correspond à /etc/init.d/keyboard-setup.dpkg-bak
zsh: exit 1 dpkg -S /etc/init.d/* | grep "no path"
Noter que je ne suis pas sous Debian mais Mint.
Sous GNU/Linux Debian Stretch, et, mon serveur minimaliste, la commande
ne me retourne rien, sans message d'erreur.
Salut Steve,
la commande suivante t'indiquera quels fichiers ne sont pas installés
par un paquet.
dpkg -S /etc/init.d/* | grep "no path"
Les autres peuvent rester: le responsable du paquet s'occupe (à son
rythme) de la migration vers systemd et conserve (autant que possible)
les scripts sysvinit pour les installations utilisant ce système.
Bonjour, j'ai regardé votre sujet en diagonale. J'ai lancé la commande,
mais, j'obtiens ce retour :
dpkg -S /etc/init.d/* | grep "no path"
dpkg-query: aucun chemin ne correspond à /etc/init.d/keyboard-setup.dpkg-bak
zsh: exit 1 dpkg -S /etc/init.d/* | grep "no path"
Noter que je ne suis pas sous Debian mais Mint.
Sous GNU/Linux Debian Stretch, et, mon serveur minimaliste, la commande
ne me retourne rien, sans message d'erreur.
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 ?
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.
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 ;)
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 ?
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.
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 ;)
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 ?
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.
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 ;)
Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :Qu'en sera-t-il de la commande service machin (start | restant | stop | reload ) ?
C'est remplacé par
systemctl (start|restart|stop|reload) le_nom_du_service
Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :
> Qu'en sera-t-il de la commande service machin (start | restant | stop | reload ) ?
C'est remplacé par
systemctl (start|restart|stop|reload) le_nom_du_service
Le 30-01-2018, à 14:15:30 +0100, Ph. Gras a écrit :Qu'en sera-t-il de la commande service machin (start | restant | stop | reload ) ?
C'est remplacé par
systemctl (start|restart|stop|reload) le_nom_du_service
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.
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%.
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.
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.
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.
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%.
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.
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.
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.
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%.
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.
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.
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 ?
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 :)
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.
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…
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 ?
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 :)
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.
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…
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 ?
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 :)
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.
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…