Ritardo lungo dopo l'avvio - upower.service richiede 26 secondi


11

Sto cercando di determinare la causa principale di un ritardo dopo l'avvio. Attualmente si utilizza Ubuntu 16.10 LTS, ma lo stesso problema si verificava nelle versioni precedenti alla 14.

Il sistema si blocca nella schermata di accesso per circa 30 secondi. Il cursore e lo schermo del mouse sono completamente congelati. Successivamente il sistema funziona normalmente.

L'output principale di systemd-analyze blameè ...

   26.653s upower.service
   6.890s NetworkManager-wait-online.service

Googling upower.service sembra che la maggior parte delle persone stia vedendo meno di 2 secondi. Come posso determinare perché upower.service impiega così tanto tempo all'avvio?

Grazie!

Risposte:


1

Fai un passo ulteriore per vedere più output usando il systemd-analyzecomando che viene aggiunto critical-chain. Questo comando presumibilmente "stampa un albero della catena di unità critiche nel tempo".

Esempio di output da systemd-analyzecomandi, che sono rilevanti per upower.service:

$ systemd-analyze blame | grep upower
           486ms upower.service

$ systemd-analyze critical-chain upower.service
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.

upower.service +486ms
└─basic.target @16.023s
  └─sockets.target @16.023s
    └─snapd.socket @15.921s +55ms
      └─sysinit.target @15.920s
        └─apparmor.service @6.264s +9.629s
          └─local-fs.target @6.147s
            └─run-user-108.mount @36.705s
              └─local-fs-pre.target @6.147s
                └─systemd-remount-fs.service @6.051s +93ms
                  └─system.slice @2.394s
                    └─-.slice @2.389s

Se l'output di cui sopra non fornisce ancora alcun suggerimento, utilizzare un altro comando systemctl status SERVICEper visualizzare l'output correlato per il SERVICE di destinazione. Questo comando stampa se il SERVICE è attualmente in esecuzione o meno e stampa anche il registro rilevante dall'ultimo avvio.

Esempio di output del systemctlcomando, che è rilevante per upower.service:

$ systemctl status upower.service
● upower.service - Daemon for power management
   Loaded: loaded (/lib/systemd/system/upower.service; disabled; vendor preset: 
   Active: active (running) since Wed 2016-09-21 23:33:23 MYT; 1min 35s ago
     Docs: man:upowerd(8)
 Main PID: 967 (upowerd)
    Tasks: 3 (limit: 512)
   CGroup: /system.slice/upower.service
           └─967 /usr/lib/upower/upowerd

Sep 21 23:33:22 HOSTNAME systemd[1]: Starting Daemon for power management...
Sep 21 23:33:23 HOSTNAME systemd[1]: Started Daemon for power management.

Un semplice controllo : esiste qualche dispositivo aggiuntivo che rimane collegato al computer senza una ragione apparente? Qualsiasi dispositivo innocente, come uno smartphone collegato alla porta USB, può rallentare o addirittura interferire con il processo di avvio del computer.

Il sistema si blocca nella schermata di accesso per circa 30 secondi. Il cursore e lo schermo del mouse sono completamente congelati. Successivamente il sistema funziona normalmente.

Il punto di svolta : la domanda sopra ha rivelato solo i sintomi, che difficilmente raccontano altro che la lentezza del caricamento del sistema.

Invece di descrivere il ritardo, considera di porsi una delle seguenti domande:

  • Quando il processo di avvio ha iniziato a rallentare?

  • Cosa è cambiato di recente con il mio computer? Come aggiornamento o personalizzazione del BIOS.

  • Ho installato hardware aggiuntivo? Come un nuovo driver di dispositivo.

  • Ho installato pacchetti aggiuntivi o aggiornato pacchetti particolari?

  • Che tipo di hardware viene utilizzato? L'hardware sta causando problemi?

La domanda non conteneva nessuna di queste informazioni, il che significa che è impossibile determinare la causa principale di qualcosa che non conosciamo. La mancanza di informazioni è una trappola per qualsiasi tentativo di risoluzione dei problemi.


0

Modifica il tuo /etc/journald.confe aggiungi spazio di archiviazione persistente. Ciò preserverà i tuoi registri dalle build precedenti.

Con questo abilitato è quindi possibile esaminare i log degli stivali precedenti per il servizio upower:

journalctl -b -1 -u upower.service

Potrebbe essere necessario disabilitare la registrazione persistente una volta terminato poiché consumerà molto spazio su disco.


ovviamente questo non farà apparire i log dagli stivali prima che tu abiliti questa opzione, non è magico.
Amias,

0

Ho avuto lo stesso problema con upower.service che richiedeva 63 secondi. Poiché ho una configurazione dualboot e ho bisogno di cambi frequenti, questo mi ha fatto impazzire. Leggere sul sito Web upower.freedesktop non ha rivelato alcun indizio su cosa stia succedendo.

Sono riuscito a risolvere il problema, anche se inavvertitamente. systemd-analyze blameora genera:

800ms snapd.firstboot.service
696ms wicd.service
...
250ms upower.service

Quindi il mio tempo di avvio è molto veloce ora. Innanzitutto, ho reinstallato upower (che non ha cambiato nulla). Quindi ho reinstallato i driver nvidia e ho anche reinstallato plasma- e questo sembra aver risolto il problema. Avevo notato che all'inizio l'installazione a doppio monitor era lenta da caricare, con il plasma (uso Kubuntu 16.04) che spesso dimenticava l'installazione. Se google 'ubuntu slow boot nvidia' ottieni parecchi successi, e questo mi ha portato a provarlo.

Scrivo questa risposta nella speranza che possa aiutare gli altri a replicare il successo. Per reinstallare reower ho seguito questa guida: fare clic su

#re-installing nvidia drivers
sudo apt-get purge nvidia-*
sudo apt-get install nvidia-current nvidia-settings

#uninstalling plasma
sudo apt-get purge kubuntu-desktop plasma-desktop
sudo apt-get autoremove

#installing plasma    
sudo apt-add-repository ppa:kubuntu-ppa/backports
sudo apt update && sudo apt full-upgrade -y

L'OP non ha dichiarato se ha una carta Nvidia o Radeon o nessuno dei due. E se la scheda Nvidia non si è saziata se sta usando binari o open source. Suggerisco che la tua risposta si applichi alla tua piattaforma che potrebbe non avere nulla a che fare con la sua. Solo chiedendogli qual è la sua piattaforma lo scopriremo di sicuro.
WinEunuuchs2Unix
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.