On 04/27/2015 03:56 PM, BERTRAND Joël wrote:
andre_debian@numericable.fr a écrit :Impossible de lancer le mode graphique que ce soit avec lightdm, gdm3, tdm-trinity... + mot de passe non reconnu ensuite (quid ?) Problème de PAM ? Et miracle, enfin "tdm-trinity" se lance avec mot de passe accepté... Aurais-je le même parcours du combattant lors du prochain boot ? Ces difficultés viennent-elles de "systemd" et faut-il le désinstaller ? (je n'ose le faire sans quelques avis...)Difficile à dire comme ça. Je n'ai eu qu'un problème de configuration de X avec systemd qui empêchait gdm3 ou kdm (je ne me souvient plus) de démarrer. En revanche en console, un startx fonctionnait toujours. Je n'ai jamais eu de problème d'authentification. Mais j'ai de gros problèmes dans les dépendances des daemons sur mon serveur de test. Pour moi, le principal problème est surtout dans le fait que systemd impose quasiment à chaque coup un reboot du serveur pour être sûr que tout se passe correctement.
BonjourSystemd n'est pas Sysvinit. Normalement, pas besoin de reboot pour que Systemd active et démarre un service/daemon.
Les commandes existent pour cela... A conserver sous la main #COMMANDES DE BASE (exemples) systemctl enable cups #Rendre effectif un service systemctl start cups #démarrer un service systemctl daemon-reload #parfois indispensable systemctl status <unit> systemctl reload <unit> systemctl systemctl list-units systemctl list-units --all #To show all installed unit files use 'systemctl list-unit-files'. systemctl list-unit-files systemctl reboot systemctl poweroff https://linuxfr.org/forums/linux-general/posts/boot-tres-lent-avec-systemd systemd-analyze #durée démarrage services journalctl -b -u systemd-udev-settle #voir ce qui bloque au boot #Pour ce qui est des unités bloquées : systemd-analyze critical-chain #JOURNAL journalctl --since="2014-11-28 14:25" https://wiki.archlinux.fr/Systemd https://wiki.debian.org/systemd https://wiki.archlinux.org/index.php/systemd#Journal -- Maderios