gnulux Bonjour, Je me permets de remonter la question car je rencontre exactement le même probème que ce soit sur mon PC fixe ou portable. A noter que j'avais déjà le souci avec Fedora 15. Pour être précis, ce quelques 40 secondes avant l'affichage de gdm-login sont apparaus après un upgrade de version : de 14->15 et de 15->16. Par contre il a fallu pour d'autres raisons que je ré-installe la 15 'classiquement' avec formatage de / et avec le DVD et là la lenteur de boot n'est pas apparu. Je confirme avoir dans les logs de démarrage des problèmes liés à sendmail et d'autres erreurs (qui me dépassent...) mais que l'arrêt de sendmail ne change pas le temps de boot : *Nov 24 08:08:12 maison-fedora kernel: [ 1.258910] ondemand governor failed, too long transition latency of HW, fallback to performance governor Nov 24 08:08:13 maison-fedora systemd[1]: Failed to read PID file /var/run/ddclient/ddclient.pid after start. The service might be broken. Nov 24 08:08:13 maison-fedora bluetoothd[1015]: Parsing /etc/bluetooth/input.conf failed: No such file or directory Nov 24 08:08:13 maison-fedora bluetoothd[1015]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory Nov 24 08:08:13 maison-fedora bluetoothd[1015]: bluetoothd[1015]: Parsing /etc/bluetooth/input.conf failed: No such file or directory Nov 24 08:08:13 maison-fedora bluetoothd[1015]: bluetoothd[1015]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory Nov 24 08:08:13 maison-fedora systemd[1]: Failed to read PID file /var/run/httpd/httpd.pid after start. The service might be broken. Nov 24 08:09:14 maison-fedora systemd[1]: Failed to read PID file /var/run/ddclient/ddclient.pid after start. The service might be broken Donc si quelqu'un a avancé sur le sujet, je suis preneur...
gnulux voila.... systemd-analyze blame 63551ms sendmail.service 60264ms sm-client.service 9173ms var-lib-nfs-rpc_pipefs.mount 8973ms fedora-loadmodules.service 8904ms udev-settle.service 6773ms remount-rootfs.service 6209ms systemd-vconsole-setup.service 5618ms media.mount 5611ms dev-hugepages.mount 5597ms sys-kernel-security.mount 5582ms sys-kernel-debug.mount 5577ms dev-mqueue.mount 5205ms systemd-remount-api-vfs.service 5176ms mysqld.service 3171ms udev-trigger.service 3039ms udev.service 2281ms fedora-readonly.service 1434ms rc-local.service 1351ms fedora-storage-init.service 1117ms fedora-storage-init-late.service 1032ms systemd-sysctl.service 796ms httpd.service 670ms NetworkManager.service 620ms nfs-lock.service 550ms netfs.service 451ms ip6tables.service 383ms mnt-home_ubuntu.mount 380ms avahi-daemon.service 378ms mnt-opt_ubuntu.mount 355ms systemd-readahead-collect.service 355ms rsyslog.service 347ms sshd-keygen.service 305ms systemd-readahead-replay.service 249ms lvm2-monitor.service 243ms systemd-logind.service 233ms console-kit-log-system-start.service 232ms sandbox.service 232ms iptables.service 215ms opt.mount 200ms boot.mount 195ms lm_sensors.service 190ms irqbalance.service 187ms bluetooth.service 170ms fedora-wait-storage.service 162ms mcelog.service 154ms dbus.service 116ms home.mount 91ms console-kit-daemon.service 69ms systemd-tmpfiles-setup.service 63ms rpcbind.service 62ms nfs-idmap.service 23ms systemd-user-sessions.service 15ms accounts-daemon.service 9ms rtkit-daemon.service 8ms acpid.service
VINDICATORs 63551ms sendmail.service 60264ms sm-client.service Ta bien désactivé ces services? tu utilise sendmail avec une configuration particulière? alors pour désactiver : su -lc'systemctl disable nomduservice.service'
gnulux Alors je vais sûrement en amuser plus d'un, mais je ne comprends pas tout : j'ai bien arrêter sendmail : >systemctl is-enabled sendmail.service disabled J'ai rebooté pour être sur mais lorsque je lance à nouveau systemd-analyze blame, j'ai toujours la même réponse : 63394ms sendmail.service 60177ms sm-client.service 12805ms fedora-loadmodules.service 11888ms systemd-vconsole-setup.service 10709ms udev-settle.service 10327ms var-lib-nfs-rpc_pipefs.mount 9015ms remount-rootfs.service 6799ms media.mount 6780ms dev-hugepages.mount 6777ms sys-kernel-security.mo normal ? Merci d'avance d'éclaire ma petite lanterne.
VINDICATORs ... Euh??? c'est quoi cette commande bizarre que ta taper??? Ta bien suivi la commande que je t'ai donné en modifiant le nom du service sendmail.service par exemple?
gnulux Oui j'ai bien utilisé ta commande pour désactiver le service. Par contre celle que j'ai tapée permet de savoir si un service est actif ou non. Enfin c'est comme ça que je l'ai compris. Du coup je me demande qui sur mon système peut lancer sendmail....
VINDICATORs euh???ok, perso moi j'utilise status à la place de is-enabled. Donc ton service doit être la dépendance d'un autre ta désactiver sm-client.service aussi? D'après moi c'est ce dernier qui pose problème. Tu ne dit pas si tu te sert de sendmail ou même si tu t'en ai servi un jour...
gnulux ok, tu as raison je n'avais pas arrêter sm-client. Merci. Vu que je suis à distance, je ne sais pas si le pb est résolu. Je vérifierai ce soir. Oui j'ai des programmes tel fail2ban qui utilisent sendmail. J'ai juste voulu voir si mon pb de boot vient de sendmail. Comme il est dit dans le fil des discussions, un bug est ouvert avec sendmail Alors j'espère que la solution définitive est peut être là.
VINDICATORs Regarde si la mise à jour dans updates-testing est bénéfique, perso j'oublie parfois que je suis en avance avec la branche stable...
gnulux Bon je reviens pour peut être donner la solution (en tout cas pour moi ça semble fonctionner) : en creusant je suis tombé sur ce bug : https://bugzilla.redhat.com/show_bug.cgi?id=708866 en lisant le fil de la discussion, j'ai ajouté ceci au démarrage : systemctl enable console-kit-daemon.service A confirmer mais à priori c'est ok 😉