Vous le savez depuis le temps que je m'exprime sur le sujet, je hais la
bouse systemd pour tout un tas de raisons. Depuis quelques jours, je
peux en ajouter une de plus. Je m'explique :
J'utilise un poste de travail diskless (debian/testing à jour du 17 mai
dernier, i7, 32 Go de mémoire, swap en iSCSI, / et /home en nfs depuis
un serveur NetBSD, biécran, Windowmaker). Je précise que j'ai mis à jour
la distribution à la suite d'un premier problème de systemd qui, pour
une raison que j'ignore (et j'ai d'autres choses à faire que d'essayer
de comprendre les effets de bord de ce truc), avait décidé de ne plus
fonctionner normalement. J'avais encore accès à la vt1, mais les autres
ne lançaient plus getty... Là encore, strictement rien dans les logs.
Lorsqu'un programme quelconque met un peu de temps à répondre, il
m'arrive depuis quelque temps que ma session X soit autoritairement
close et que je me retrouve sous wdm. C'est assez énervant. Les logs ne
contiennent que ceci :
May 19 07:47:57 hilbert systemd[1]: Created slice User Slice of UID 0.
May 19 07:47:57 hilbert systemd[1]: Starting User Runtime Directory
/run/user/0...
May 19 07:47:57 hilbert systemd[1]: Finished User Runtime Directory
/run/user/0.
May 19 07:47:57 hilbert systemd[1]: Starting User Manager for UID 0...
May 19 07:47:57 hilbert systemd[573558]: gpgconf: erreur d'exécution de
« /usr/lib/gnupg/scdaemon » : il n'est sans doute pas installé
May 19 07:47:59 hilbert systemd[573552]: Reached target Paths.
May 19 07:47:59 hilbert systemd[573552]: Reached target Timers.
May 19 07:47:59 hilbert systemd[573552]: Starting D-Bus User Message Bus
Socket.
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG network
certificate management daemon.
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache (access for web browsers).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache (restricted).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent (ssh-agent emulation).
May 19 07:47:59 hilbert systemd[573552]: Listening on GnuPG
cryptographic agent and passphrase cache.
May 19 07:47:59 hilbert systemd[573552]: Listening on debconf
communication socket.
May 19 07:47:59 hilbert systemd[573552]: Condition check resulted in
Sound System being skipped.
May 19 07:47:59 hilbert systemd[573552]: Listening on D-Bus User Message
Bus Socket.
May 19 07:47:59 hilbert systemd[573552]: Reached target Sockets.
May 19 07:47:59 hilbert systemd[573552]: Reached target Basic System.
May 19 07:47:59 hilbert systemd[573552]: Condition check resulted in
Sound Service being skipped.
May 19 07:47:59 hilbert systemd[573552]: Reached target Main User Target.
May 19 07:47:59 hilbert systemd[573552]: Startup finished in 1.860s.
Je ne vois pas bien le rapport avec ce que j'observe. Je constate aussi
que toutes les instances de WM sont closes (même celles qui tournent
sous :1 et :2). De manière concomitante, certains processus se prennent
des SIGBUS.
Je n'ai strictement rien d'autre dans les logs, pas la plus petite
erreur mémoire, rien. Juste une déconnexion des sessions X pour une
raison indéterminée et, visiblement, à la demande de systemd.
[...] Ce qui serait vraiment intéressant, c'est que Debian propose avec ou sans systemd (pour tous ses paquets d'ailleurs),
Cela s'appelle devuan.org -- Daniel
didier gaumet
Disons que j'ai peut-être tort, mais je pense qu'ici tu envisages ton problème d'un manière plus subjective que rationnelle et que ça te pénalise dans sa résolution :-) Je suis loin d'être compétent sur les systèmes de démarrage pseudo-unix en général et Systemd en particulier, qui ne se résume pas à ce rôle, donc je ne vais pas trop m'étendre. Mais je pense que l'un des points qui gênent, souvent inconsciemment, les critiques de Systemd est que de facto, on a transféré des responsabilités: autrefois sous SysV, le caractère fonctionnel ou non d'un daemon était plus ou moins en partie caractérisé par la qualité de son script Sysv de démarrage, écrit par l'équipe de développement upstream du logiciel concerné. Avec Systemd j'ai l'impression qu'une partie du caractère opérationnel du système d'exploitation et du logiciel concerné (via son service) repose -c'est nouveau- sur l'administrateur du système d'exploitation. En gros, avec SysV, suivant où était placé le script du dameon dans la chaîne d'initialisation, c'était binaire: ça démarrait et ça fonctionnait, ou non. Systemd demanderait plutôt une démarche d'intégration de système et pénaliserait l'administrateur du système par un fonctionnement non-optimisé lorsque la réflexion de l'administrateur a été trop vague ("Systemd, me fais pas chier, j'veux qu'tu démarres daemon1, pose pas de questions") Je pense que la majorité des problèmes se pose pour ceux qui souhaitent utiliser Systemd de la même manière que SysV auparavant alors que ce n'est pas prévu (tu as déjà dû connaître ça du temps de la guéguerre SysV/rc: "SysV c'est de la merde", et on cause même pas des ordonnancements par cartes perforées) Que l'on soit heureux ou malheureux de ces tendances, de facto: - Debian c'est basé sur Linux (Debian/Hurd est assez anecdotique, Debian/kNetBSD est mort-né, Debian/kFreeBSD n'a pas vraiment survécu) - Linux c'est de plus en plus Systemd en termes d'adoption - selon moi en OS libres sur desktop ou laptop, sortir de Linux c'est chercher les ennuis (j'ai utilisé NetBSD plus que Free ou Open, y a très longtemps). En desktop ça s'est beaucoup dégradé, en laptop ça n'a jamais été vraiment pertinent (opinion perso, comme le reste). (Dans la recherche Distrowatch suscitée figurent tous les BSD) Donc, pour moi, soit tu mets ton dégoût de côté et tu solutionneras plus facilement tes problèmes Systemd par une approche moins subjective ("quelle merde ce truc, c'est normal que ça marche pas"), soit le dégoût en question est trop fort et tu sautes le pas pour te passer de Systemd (ce qui peut signifier cesser d'utiliser certains logiciels ou certains OS) KISS et le principe "tout-est-fichier" c'est bien tant que ça ne devient pas un dogme qui empêche l'atteinte de tes objectifs. Le paroxysme du KISS c'est l'immobilisme et y a eu une vie informatique avant le "tout-est-fichier" :-) Je reconnais bien volontiers que je suis un utilisateur basique de laptop donc que je ne figure pas parmi ceux que Systemd peut le plus gêner :-) Fin de la parenthèse, je m'arrête là :-)
Disons que j'ai peut-être tort, mais je pense qu'ici tu envisages ton
problème d'un manière plus subjective que rationnelle et que ça te
pénalise dans sa résolution :-)
Je suis loin d'être compétent sur les systèmes de démarrage pseudo-unix
en général et Systemd en particulier, qui ne se résume pas à ce rôle,
donc je ne vais pas trop m'étendre.
Mais je pense que l'un des points qui gênent, souvent inconsciemment,
les critiques de Systemd est que de facto, on a transféré des
responsabilités: autrefois sous SysV, le caractère fonctionnel ou non
d'un daemon était plus ou moins en partie caractérisé par la qualité de
son script Sysv de démarrage, écrit par l'équipe de développement
upstream du logiciel concerné. Avec Systemd j'ai l'impression qu'une
partie du caractère opérationnel du système d'exploitation et du
logiciel concerné (via son service) repose -c'est nouveau- sur
l'administrateur du système d'exploitation.
En gros, avec SysV, suivant où était placé le script du dameon dans la
chaîne d'initialisation, c'était binaire: ça démarrait et ça
fonctionnait, ou non. Systemd demanderait plutôt une démarche
d'intégration de système et pénaliserait l'administrateur du système par
un fonctionnement non-optimisé lorsque la réflexion de l'administrateur
a été trop vague ("Systemd, me fais pas chier, j'veux qu'tu démarres
daemon1, pose pas de questions")
Je pense que la majorité des problèmes se pose pour ceux qui souhaitent
utiliser Systemd de la même manière que SysV auparavant alors que ce
n'est pas prévu (tu as déjà dû connaître ça du temps de la guéguerre
SysV/rc: "SysV c'est de la merde", et on cause même pas des
ordonnancements par cartes perforées)
Que l'on soit heureux ou malheureux de ces tendances, de facto:
- Debian c'est basé sur Linux (Debian/Hurd est assez anecdotique,
Debian/kNetBSD est mort-né, Debian/kFreeBSD n'a pas vraiment survécu)
- Linux c'est de plus en plus Systemd en termes d'adoption
- selon moi en OS libres sur desktop ou laptop, sortir de Linux c'est
chercher les ennuis (j'ai utilisé NetBSD plus que Free ou Open, y a très
longtemps). En desktop ça s'est beaucoup dégradé, en laptop ça n'a
jamais été vraiment pertinent (opinion perso, comme le reste). (Dans la
recherche Distrowatch suscitée figurent tous les BSD)
Donc, pour moi, soit tu mets ton dégoût de côté et tu solutionneras plus
facilement tes problèmes Systemd par une approche moins subjective
("quelle merde ce truc, c'est normal que ça marche pas"), soit le dégoût
en question est trop fort et tu sautes le pas pour te passer de Systemd
(ce qui peut signifier cesser d'utiliser certains logiciels ou certains OS)
KISS et le principe "tout-est-fichier" c'est bien tant que ça ne devient
pas un dogme qui empêche l'atteinte de tes objectifs. Le paroxysme du
KISS c'est l'immobilisme et y a eu une vie informatique avant le
"tout-est-fichier" :-)
Je reconnais bien volontiers que je suis un utilisateur basique de
laptop donc que je ne figure pas parmi ceux que Systemd peut le plus
gêner :-)
Disons que j'ai peut-être tort, mais je pense qu'ici tu envisages ton problème d'un manière plus subjective que rationnelle et que ça te pénalise dans sa résolution :-) Je suis loin d'être compétent sur les systèmes de démarrage pseudo-unix en général et Systemd en particulier, qui ne se résume pas à ce rôle, donc je ne vais pas trop m'étendre. Mais je pense que l'un des points qui gênent, souvent inconsciemment, les critiques de Systemd est que de facto, on a transféré des responsabilités: autrefois sous SysV, le caractère fonctionnel ou non d'un daemon était plus ou moins en partie caractérisé par la qualité de son script Sysv de démarrage, écrit par l'équipe de développement upstream du logiciel concerné. Avec Systemd j'ai l'impression qu'une partie du caractère opérationnel du système d'exploitation et du logiciel concerné (via son service) repose -c'est nouveau- sur l'administrateur du système d'exploitation. En gros, avec SysV, suivant où était placé le script du dameon dans la chaîne d'initialisation, c'était binaire: ça démarrait et ça fonctionnait, ou non. Systemd demanderait plutôt une démarche d'intégration de système et pénaliserait l'administrateur du système par un fonctionnement non-optimisé lorsque la réflexion de l'administrateur a été trop vague ("Systemd, me fais pas chier, j'veux qu'tu démarres daemon1, pose pas de questions") Je pense que la majorité des problèmes se pose pour ceux qui souhaitent utiliser Systemd de la même manière que SysV auparavant alors que ce n'est pas prévu (tu as déjà dû connaître ça du temps de la guéguerre SysV/rc: "SysV c'est de la merde", et on cause même pas des ordonnancements par cartes perforées) Que l'on soit heureux ou malheureux de ces tendances, de facto: - Debian c'est basé sur Linux (Debian/Hurd est assez anecdotique, Debian/kNetBSD est mort-né, Debian/kFreeBSD n'a pas vraiment survécu) - Linux c'est de plus en plus Systemd en termes d'adoption - selon moi en OS libres sur desktop ou laptop, sortir de Linux c'est chercher les ennuis (j'ai utilisé NetBSD plus que Free ou Open, y a très longtemps). En desktop ça s'est beaucoup dégradé, en laptop ça n'a jamais été vraiment pertinent (opinion perso, comme le reste). (Dans la recherche Distrowatch suscitée figurent tous les BSD) Donc, pour moi, soit tu mets ton dégoût de côté et tu solutionneras plus facilement tes problèmes Systemd par une approche moins subjective ("quelle merde ce truc, c'est normal que ça marche pas"), soit le dégoût en question est trop fort et tu sautes le pas pour te passer de Systemd (ce qui peut signifier cesser d'utiliser certains logiciels ou certains OS) KISS et le principe "tout-est-fichier" c'est bien tant que ça ne devient pas un dogme qui empêche l'atteinte de tes objectifs. Le paroxysme du KISS c'est l'immobilisme et y a eu une vie informatique avant le "tout-est-fichier" :-) Je reconnais bien volontiers que je suis un utilisateur basique de laptop donc que je ne figure pas parmi ceux que Systemd peut le plus gêner :-) Fin de la parenthèse, je m'arrête là :-)
Fabien R
On 19/05/2020 11:33, BERTRAND Joël wrote:
NoSpam a écrit :
Le 19/05/2020 à 10:15, BERTRAND Joël a écrit :
[...] Ce qui serait vraiment intéressant, c'est que Debian propose avec ou sans systemd (pour tous ses paquets d'ailleurs),
Cela s'appelle devuan.org
Sur le papier, oui. Mais as-tu testé devuan ?
Moi, je l'utilise à la place de debian. Ca fonctionne très bien. L'audience n'est pas
assez grande pour en faire un système utilisable sans problème.
Tu peux développer ? -- Fabien
On 19/05/2020 11:33, BERTRAND Joël wrote:
NoSpam a écrit :
Le 19/05/2020 à 10:15, BERTRAND Joël a écrit :
[...]
Ce qui serait vraiment intéressant, c'est que Debian propose avec ou
sans systemd (pour tous ses paquets d'ailleurs),
Cela s'appelle devuan.org
Sur le papier, oui. Mais as-tu testé devuan ?
Moi, je l'utilise à la place de debian.
Ca fonctionne très bien.
L'audience n'est pas
assez grande pour en faire un système utilisable sans problème.
