je me doute bien que chez certaines personnes, systemd ne pose aucun problème.
Sur un de mes postes, si je démarre avec systemd, alors:
- Impossible de faire fonctionner PowerDNS-recursor, il se relance en boucle. Je n'ai aucun fichier personnalisé concernant pdns-recursor. Certains vont dire que c'est la faute des mainteneurs de pdns-recursor, ben voyons.
- La mise en veille de l'écran et son verrouillage peut se bloquer. Je suis obligé d'attendre que le clavier se débloque (5 ou 10 minutes) pour pouvoir basculer en mode console et utiliser loginctl unlock-sessions. (ou bien de me connecter via ssh pour le faire)
- Il faut parfois beaucoup temps pour éteindre la machine (j'ai ce problème sur tout les postes bureautique avec systemd, il attend un truc... je ne sais pas quoi)
Alors que sous Sys V init, tout fonctionne bien.
- pdns-recursor se lance sans accrocs, et fait son job.
- Pas de soucis particulier avec la mise en veille et le verrouillage/déverrouillage de l'écran
- L'extinction est rapide, bien plus rapide qu'avec systemd.
Si systemd n'était pas un (削除) bricolage (削除ここまで) infâme, et si c'était transparent pour mon usage, ça passerait mieux.
Sur les serveurs, systemd me pose aussi problème, heureusement que je les redémarre moins souvent.
En relançant un service il y a une erreur, (que ce soit avec reload, ou configtest quand c'est disponible)
- avec systemd je dois ouvrir un autre terminal pour avoir les détails dans les logs.
- avec sys V init, j'ai directement l'information complète, ce qui est nettement plus pratique, vous en conviendrez.
J'ai cherché comment préciser à systemd de me sortir quand même l'information directement, et c'est tellement bien planqué que je n'ai pas trouvé.
Je n'écris pas de scripts d'init, ou bien je le fais une fois tous les deux ans. Systemd ne m'apporte rien de positif. Je ne pense pas que tous les admins-sys écrivent tous les jours des scripts d'init. Alors c'est quoi qui est bien avec systemd pour la plupart des admin-sys?
Contrairement à ce qu'on peut lire parfois, systemd à été forcé dans Debian. Pour éviter un travail monstrueux pour les mainteneurs, puisque systemd n'est pas compatible avec les scripts d'init de Sys V init (ce serait trop beau, c'est seulement superficiel).
Je veux bien des évolutions, des solutions, mais systemd n'est pas abouti.
Je suppose que pour des architectures un peu ancienne ou exotique, Redhat n'en ai rien à foutre, ce qui expliquerait les dysfonctionnement de systemd en dehors des serveurs Dell, HP et Microtic.
Il est clair que Redhat n'en a rien à faire de Linux sur des postes bureautique. J'aimerai voir le contraire.
Vous pouvez moinser, ça ne me fera pas changer mon avis (ni mon expérience, malheureusement)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Systemd
Posté par GG (site web personnel) . En réponse au journal Les Init alter-natifs. Évalué à 3. Dernière modification le 03 décembre 2016 à 18:30.
Bonsoir,
je me doute bien que chez certaines personnes, systemd ne pose aucun problème.
Sur un de mes postes, si je démarre avec systemd, alors:
- Impossible de faire fonctionner PowerDNS-recursor, il se relance en boucle. Je n'ai aucun fichier personnalisé concernant pdns-recursor. Certains vont dire que c'est la faute des mainteneurs de pdns-recursor, ben voyons.
- La mise en veille de l'écran et son verrouillage peut se bloquer. Je suis obligé d'attendre que le clavier se débloque (5 ou 10 minutes) pour pouvoir basculer en mode console et utiliser loginctl unlock-sessions. (ou bien de me connecter via ssh pour le faire)
- Il faut parfois beaucoup temps pour éteindre la machine (j'ai ce problème sur tout les postes bureautique avec systemd, il attend un truc... je ne sais pas quoi)
Alors que sous Sys V init, tout fonctionne bien.
- pdns-recursor se lance sans accrocs, et fait son job.
- Pas de soucis particulier avec la mise en veille et le verrouillage/déverrouillage de l'écran
- L'extinction est rapide, bien plus rapide qu'avec systemd.
Si systemd n'était pas un
(削除) bricolage (削除ここまで)infâme, et si c'était transparent pour mon usage, ça passerait mieux.Sur les serveurs, systemd me pose aussi problème, heureusement que je les redémarre moins souvent.
En relançant un service il y a une erreur, (que ce soit avec reload, ou configtest quand c'est disponible)
- avec systemd je dois ouvrir un autre terminal pour avoir les détails dans les logs.
- avec sys V init, j'ai directement l'information complète, ce qui est nettement plus pratique, vous en conviendrez.
J'ai cherché comment préciser à systemd de me sortir quand même l'information directement, et c'est tellement bien planqué que je n'ai pas trouvé.
Je n'écris pas de scripts d'init, ou bien je le fais une fois tous les deux ans. Systemd ne m'apporte rien de positif. Je ne pense pas que tous les admins-sys écrivent tous les jours des scripts d'init. Alors c'est quoi qui est bien avec systemd pour la plupart des admin-sys?
Contrairement à ce qu'on peut lire parfois, systemd à été forcé dans Debian. Pour éviter un travail monstrueux pour les mainteneurs, puisque systemd n'est pas compatible avec les scripts d'init de Sys V init (ce serait trop beau, c'est seulement superficiel).
Je veux bien des évolutions, des solutions, mais systemd n'est pas abouti.
Je suppose que pour des architectures un peu ancienne ou exotique, Redhat n'en ai rien à foutre, ce qui expliquerait les dysfonctionnement de systemd en dehors des serveurs Dell, HP et Microtic.
Il est clair que Redhat n'en a rien à faire de Linux sur des postes bureautique. J'aimerai voir le contraire.
Vous pouvez moinser, ça ne me fera pas changer mon avis (ni mon expérience, malheureusement)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html