web-dev-qa-db-fra.com

Gestionnaire de réseau Ubuntu 15.04 provoquant un démarrage lent

Depuis la mise à niveau de 14.10 à 15.04 il y a quelques jours, le temps de démarrage, l’écran de connexion du système d’exploitation de Grub OS, est passé de 12 secondes à environ 40 secondes. C’est ma chaîne critique systemd-analyse sortie:

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

    graphical.target @37.433s
    └─multi-user.target @37.433s
      └─getty.target @37.432s
        └─[email protected] @37.432s
          └─systemd-user-sessions.service @35.906s +9ms
            └─remote-fs.target @35.904s
              └─media-XalnasStorage.mount @35.849s +53ms
                └─network-online.target @35.846s
                  └─network.target @11.636s
                    └─NetworkManager.service @11.502s +132ms
                      └─basic.target @11.487s
                        └─sockets.target @11.487s
                          └─avahi-daemon.socket @11.487s
                            └─sysinit.target @11.485s
                              └─networking.service @11.333s +65ms
                                └─apparmor.service @11.269s +63ms
                                  └─local-fs.target @11.268s
                                    └─media-TStore1.mount @10.331s +936ms
                                      └─local-fs-pre.target @10.328s
                                        └─systemd-remount-fs.service @10.320s +6ms
                                          └─systemd-fsck-root.service @10.303s +15ms
                                            └─systemd-journald.socket @151ms
                                              └─-.slice @150ms

Il semble y avoir un problème avec le service de gestionnaire de réseau.

Le haut du journal de blâme de systemd-analyse ressemble à ceci:

     24.209s NetworkManager-wait-online.service
     10.056s systemd-udev-settle.service
      1.499s plymouth-quit-wait.service
       936ms media-TStore1.mount
       487ms dev-disk-by\x2duuid-920a92b0\x2d6e65\x2d4a7a\x2d855d\x2d81cb436cd85f.device
       425ms [email protected]
       421ms [email protected]
       407ms media-TStore2.mount
       267ms gpu-manager.service
       215ms plymouth-read-write.service
       209ms [email protected]
       132ms NetworkManager.service
        83ms ModemManager.service

La version complète peut être vue ici .

On peut également voir la sortie de systemd-analyse ici .

Merci pour votre temps.

bootnetwork-manager15.04systemd
13
alx.balmus

Vous pouvez modifier le délai d’exécution de nm-online en 10:

Éditez /lib/systemd/system/NetworkManager-wait-online.service en tant que root ou en utilisant Sudo.

Cherchez les lignes:

[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q --timeout=30

Changez 30 en ce que vous voulez. 10 a bien fonctionné pour moi.

Mais méfiez-vous , cela peut endommager les services qui en dépendent.

Source

13
billgates

J'ai déjà rencontré le même problème auparavant, NetworkManager prenant environ 8 secondes. Il y a trois façons de résoudre ce problème:

  1. Désactiver la connexion automatiquement pour votre connexion

    modifier les connexions > sélectionnez votre connexion> modifier et désactiver la connexion automatiquement

    enter image description here

  2. Vous pouvez simplement désactiver Enable networking à partir de l'indicateur de réseau.

  3. Vous pouvez désactiver le service en exécutant cette commande

    systemctl disable NetworkManager-wait-online.service
14
Mohamed Slama

Désactivez dhcp sur eth0 interface.

Si dhcp est configuré sur eth0 et que le fil n'est pas connecté, le système continuera à rechercher une adresse IP pour affecter votre périphérique jusqu'à l'expiration de la demande d'adresse IP, avant que le démarrage ne se poursuive.

Pour vérifier si cela résoudrait votre problème, exécutez Sudo /etc/init.d/networking restart et notez le temps nécessaire au redémarrage de ce service.

Le service redémarrera dans un rien de temps. S'il n'y a pas de problème avec l'interface eth0, sinon, un délai et un délai d'attente longs seront présentés.

4
Peter