Linux Quimper

Retard au démarrage du Wifi

Autrefois, il y a quelques semaines, je pouvais accéder immédiatement à Internet, soit avec Thunderbird, soit avec Firefox, immédiatement au lancement de l’ordinateur.
Mais désormais l’icône du Wifi tarde à apparaître de façon aléatoire ; le lancement de l’un de ces deux programmes échoue.
Comment obliger le Wifi à démarrer « tout de suite », diouzhtu, comme avant, et non avec un retard de quelques secondes à dizaines de secondes ?

Bonjour Michel,

Quelle distribution et quel environnement de bureau utilises-tu ?
Quel est le modèle du PC, ou en tout cas de la carte wifi ?
Tu parles d’un démarrage de l’ordinateur ou d’une sortie de veille ?

Distribution 18.04 Gnome.
NUC Intel, je ne connais pas la carte Wifi en détail.
(lsusb : Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78) )
Il s’agit d’un démarrage à froid, jamais de sortie de veille.

Je soupçonne une mise à jour ?

Ce qui m’intrigue c’est la nouveauté de ce comportement, sur une machine âgée de trois ans…
Le Wifi une fois établi, il n’y aucun autre problème.

Peux-tu donner la sortie de la commande suivante :

systemd-analyze blame

Peut-être que network-manager est retardé par un autre service.

Vincent, voilà :

      6.306s NetworkManager-wait-online.service
      5.037s bolt.service
      3.506s plymouth-quit-wait.service
      1.664s dev-nvme0n1p2.device
      1.180s tor@default.service
      1.051s snapd.service
       599ms fwupd.service
       391ms dev-loop2.device
       387ms dev-loop3.device
       381ms dev-loop1.device
       369ms dev-loop4.device
       358ms dev-loop7.device
       349ms dev-loop5.device
       331ms dev-loop6.device
       273ms ua-messaging.service
       268ms apparmor.service
       263ms udisks2.service
       233ms networkd-dispatcher.service
       170ms systemd-logind.service
       162ms ModemManager.service
       156ms systemd-rfkill.service
       142ms accounts-daemon.service
       138ms timidity.service
       133ms plymouth-read-write.service
       131ms networking.service
       125ms snap-gnome\x2dsystem\x2dmonitor-157.mount
       112ms snap-gnome\x2d3\x2d34\x2d1804-72.mount
       109ms thermald.service
       106ms snap-gnome\x2dcalculator-884.mount
       106ms bluetooth.service
       105ms systemd-journal-flush.service
       103ms alsa-restore.service
        98ms systemd-udev-trigger.service
        98ms grub-common.service
        97ms snap-core18-2066.mount
        95ms NetworkManager.service
        95ms avahi-daemon.service
        92ms lm-sensors.service
        85ms apport.service
        81ms snap-gtk\x2dcommon\x2dthemes-1515.mount
        79ms snap-snapd-12057.mount
        79ms snap-gnome\x2dlogs-103.mount
        75ms gpu-manager.service
        75ms pppd-dns.service
        74ms keyboard-setup.service
        71ms dev-loop0.device
        64ms tor.service
        61ms packagekit.service
        60ms rsyslog.service
        58ms user@121.service
        57ms systemd-journald.service
        56ms snap-gnome\x2dcharacters-708.mount
        49ms snapd.apparmor.service
        49ms systemd-resolved.service
        48ms systemd-udevd.service
        44ms upower.service
        43ms systemd-timesyncd.service
        41ms wpa_supplicant.service
        41ms ssh.service
        40ms snapd.seeded.service
        37ms systemd-fsck@dev-disk-by\x2duuid-A660\x2d04D4.service
        35ms speech-dispatcher.service
        34ms user@1000.service
        32ms systemd-modules-load.service
        29ms systemd-tmpfiles-setup-dev.service
        29ms gdm.service
        29ms kerneloops.service
        25ms systemd-tmpfiles-clean.service
        22ms swapfile.swap
        21ms polkit.service
        20ms plymouth-start.service
        19ms colord.service
        17ms systemd-fsck@dev-disk-by\x2duuid-1389a8f6\x2dc56d\x2d4124\x2dba93\x2dc4250e42697e.service
        17ms systemd-user-sessions.service
        15ms systemd-tmpfiles-setup.service
        14ms systemd-remount-fs.service
        12ms kmod-static-nodes.service
        12ms systemd-sysctl.service
        12ms dev-mqueue.mount
         9ms dev-hugepages.mount
         8ms ufw.service
         7ms home.mount
         7ms systemd-update-utmp-runlevel.service
         7ms dns-clean.service
         7ms ureadahead-stop.service
         7ms console-setup.service
         6ms sys-kernel-debug.mount
         6ms boot-efi.mount
         6ms systemd-update-utmp.service
         5ms sys-kernel-config.mount
         4ms systemd-random-seed.service
         4ms rtkit-daemon.service
         3ms setvtrgb.service
         2ms sys-fs-fuse-connections.mount
         2ms snapd.socket

Tu as des périphériques Thunderbolt sur ta machine ?

Si ce n’est pas le cas, tu peux déjà désactiver bolt, ça sera toujours 5 secondes de gagnées :

sudo systemctl disable bolt.service

Après un redémarrage, si le problème persiste, tu peux aussi désactiver NetworkManager-wait-online :

sudo systemctl disable NetworkManager-wait-online.service

Mais à mon avis ce n’est pas le problème. Si je comprends bien, la connexion au Wi-Fi met du temps à s’établir une fois sur le bureau

Vincent,
Merci pour la désactivation du Thunderbolt, je n’ai pas de périphérique de ce type. C’est bien du Apple ?
Il faudra un peu de temps pour voir, ou ne pas voir, si le phénomène se reproduit.

« Si je comprends bien, la connexion au Wi-Fi met du temps à s’établir une fois sur le bureau… »
Tout allait bien pendant trois ans… Puis un retard à l’activation du Wifi, de façon aléatoire.

Après passage dans la documentation de systemd, il semble que le « bolt.service » ne soit pas désactivable :

~$ sudo systemctl disable bolt.service

~$ systemctl status bolt.service
● bolt.service - Thunderbolt system service

   Loaded: loaded (/lib/systemd/system/bolt.service; static; vendor preset: enabled)
   Active: active (running) since Mon 2021-06-21 20:22:00 CEST; 29min ago
     Docs: man:boltd(8)
 Main PID: 1085 (boltd)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/bolt.service
           └─1085 /usr/lib/x86_64-linux-gnu/boltd
juin 21 20:22:00 nvme boltd[1085]: power: guard '1' for 'boltd' deactivated
juin 21 20:22:00 nvme boltd[1085]: power: shutdown scheduled (T-20,00s)
juin 21 20:22:00 nvme systemd[1]: Started Thunderbolt system service.
juin 21 20:22:20 nvme boltd[1085]: power: setting force_power to OFF
juin 21 20:23:06 nvme boltd[1085]: power: setting force_power to ON
juin 21 20:23:06 nvme boltd[1085]: power: guard '2' for 'fwupd' active
juin 21 20:23:26 nvme boltd[1085]: power: got event for guard '2' (10)
juin 21 20:23:26 nvme boltd[1085]: power: guard '2' for 'fwupd' deactivated
juin 21 20:23:26 nvme boltd[1085]: power: shutdown scheduled (T-20,00s)
juin 21 20:23:46 nvme boltd[1085]: power: setting force_power to OFF

Ton avis ?

Cette icône c’est plus de la déco qu’une indication fidèle, il ne faut pas trop s’y fier ! Il faudrait faire un « ip a » très tôt, peut-être que tu es connecté à internet et que c’est juste pas affiché comme tel (d’ailleurs c’est très probable avec le « nm-wait-online ») ?
Je serai prêt à parier assez que que tu es connecté à internet avant que l’indicateur de connexion graphique n’en fasse la notif.

(Après je ne parierai pas trop gros, si tu as une mauvaise connexion wifi, ça peut mouliner un peu).

A priori, non, il n’est pas connecté au réseau :

Je crois que dans ce cas, tu peux essayer avec mask plutôt que disable :

sudo systemctl mask bolt.service

Tu as essayé de désactiver NetworkManager-wait-online.service ?

Je crois que dans ce cas, tu peux essayer avec mask plutôt que disable :

sudo systemctl mask bolt.service

Pas de changement… Mais avec : sudo NetworkManager-wait-online.service

le début de

systemd-analyze blame
donne :
      3.305s plymouth-quit-wait.service
      1.400s dev-nvme0n1p2.device
      1.188s tor@default.service
      1.044s snapd.service
       532ms apparmor.service
       419ms networkd-dispatcher.service
       392ms plymouth-read-write.service

ce qui est tout à fait différent, les deux lignes suivantes disparaissent :

Il reste à attendre si le phénomène se reproduit.

Oui, un retard « long » (10 secondes ?) hier.
Pourtant…
$ systemd-analyze blame
3.334s plymouth-quit-wait.service
1.736s dev-nvme0n1p2.device
1.165s tor@default.service
1.039s snapd.service
625ms fwupd.service
420ms apparmor.service
398ms networkd-dispatcher.service
366ms dev-loop1.device