systemd et fichiers dans /etc/init.d/
Le
steve

Salut,
M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
une place plus que négligeable, mais ce serait quand même plus élégant
de ne plus avoir de restes de l'ancien système.
Merci
Steve
M'intéressant un peu (plus) à systemd (qui tourne sur ma machine
principale), je me demandais si les fichiers placés dans /etc/init.d/
sont encore utilisés ou s'ils ne sont là que pour une éventuelle
compatibilité avec les systèmes utilisant SysVInit plutôt que systemd.
Dans la négative, y a-t-il un moyen propre de nettoyer le système de ces
fichiers inutiles ? Je veux dire, sans 'rm -rf /etc/init.d', car ces
fichiers sont présents dans les paquets Debian. Je sais qu'ils prennent
une place plus que négligeable, mais ce serait quand même plus élégant
de ne plus avoir de restes de l'ancien système.
Merci
Steve
d'après
https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/
"[...]
Q: I have a native systemd service file and a SysV init script installed
which share the same basename, e.g.
/usr/lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which
one wins?
A: If both files are available the native unit file always takes
precedence and the SysV init script is ignored, regardless whether
either is enabled or disabled. Note that a SysV service that is enabled
but overridden by a native service does not have the effect that the
native service would be enabled, too. Enabling of native and SysV
services is completely independent. Or in other words: you cannot enable
a native service by enabling a SysV service by the same name, and if a
SysV service is enabled but the respective native service is not, this
will not have the effect that the SysV script is executed.
[...]"
ce qui semble indiquer que tu peux retirer toute ce qui est présent dans
/etc/init.d/ pour lequel tu peux trouver un équivalent fonctionnel dans
/usr/lib/systemd/system/ (pas forcément avec le même nom).
'soir
Surtout pas, malheureux ! Le blob systemd va rechercher les modules
dans /lib/systemd mais s'il ne trouve rien, il convertit à la volée ce
qui est dans /etc/init.d dans son format pour tenter de faire
difficillement ce que l'ancien init SysV faisait très simplement. Ce qui
permet d'ailleurs des effets de bord assez rigolos entre deux versions
de la chose.
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.
Cordialement,
JKB
PS: oui, je pense que ça s'est vu que je n'aime pas cette bouse... Et
plus je rentre dedans, pire c'est.
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.
On peut voir quels services n'ont pas encore été migrés en listant
les fichiers se trouvant dans `/run/systemd/generator.late/`.
Donc grosso-modo, si tu n'as rien installé par toi-meme hors du
système de paquets, il n'y a rien à enlever.
PS: si tu veux faire un peu plus de nettoyage, regarde du coté de
systemd-network, qui permettra d'enlever des fichiers comme
/etc/network/interfaces (à moins que network-manager tourne déjà sur
la machine).
Amicalement,
--
Charles Plessy
Tsurumi, Kanagawa, Japon
Du genre ? As-tu des exemples concrets ?
Mais ces fichiers seront réinstallés à la prochaine maj. Donc assez
inutile.
Rien à lui reprocher pour le moment pour un usage domestique.
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.boot
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.start
dpkg-query: aucun chemin ne correspond à /etc/init.d/.depend.stop
dpkg-query: aucun chemin ne correspond à /etc/init.d/plexmediaserver.dpkg-bak
acct.service
cpufrequtils.service
fetchmail.service
geneweb.service
graphical.target.wants
gwsetup.service
hddtemp.service
loadcpufreq.service
multi-user.target.wants
ntp.service
speech-dispatcher.service
stunnel4.service
sysstat.service
Merci, c'est très intéressant.
Ok.
Je n'ai rien qui ressemble à un paquet nommé ainsi.
Encore merci pour ces renseignements.
Belle journée
Steve
Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
man insserv
Je ne sais pas si ça sert encore. Mais il semble être trop tôt pour l'enlever:
$ sudo apt purge insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
systemd-shim
The following packages will be REMOVED:
init* initscripts* insserv* systemd-sysv* sysv-rc*
The following NEW packages will be installed:
systemd-shim
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
init systemd-sysv (due to init)
Bon à effacer
Le Tue, Jan 30, 2018 at 09:05:02AM +0100, steve a écrit :
(désolé pour le « d » manquant)
$ dpkg -S systemd-networkd
systemd: /lib/systemd/systemd-networkd-wait-online
systemd: /lib/systemd/systemd-networkd
systemd: /lib/systemd/system/systemd-networkd.socket
systemd: /usr/share/man/man8/systemd-networkd-wait-online.8.gz
systemd: /usr/share/man/man8/systemd-networkd-wait-online.service.8.gz
systemd: /usr/share/man/man8/systemd-networkd.service.8.gz
systemd: /lib/systemd/system/systemd-networkd-wait-online.service
systemd: /lib/systemd/system/systemd-networkd.service
systemd: /usr/share/man/man8/systemd-networkd.8.gz
Amicalement,
--
Charles Plessy
Tsurumi, Kanagawa, Japon
A étudier donc…
En effet.
Argh, je cherchais un paquet nommé ainsi…
Merci pour les précisions.
Steve
Si le système tourne à 100% avec SystemD, oui.
C'est remplacé par
systemctl (start|restart|stop|reload) le_nom_du_service
itou
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).
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 !
JKB
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.