Spor shutdown

Ubuntu desktop sasvim lijepo radi na mom notebooku. Boot je brz, shutdown još brži, što se može zahvaliti SSD disku i i7 procesoru. No povremeno se dogodi da shutdown traje jako dugo, preko minute, što izgleda kao vječnost kad se jednom navikneš na brzinu. Čovjek to istrpi nekoliko puta, a onda ga počne nervirati. Na kraju ga zagolica radoznalost. Treba otkriti što se tu događa.

Najprije sam želio eliminirati greške na disku kao mogući uzrok usporavanja. Badblocks "by default" radi read-only test. Ako ga želimo natjerati da popravi greške, treba bootati s CD-a ili USB sticka, pa pustiti badblocks na disk koji nije montiran.

$ sudo badblocks -vs /dev/sda
Checking blocks 0 to 156290903
Checking for bad blocks (read-only test): done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Parametri su -v za verbose, a -s za show progress, da ne bismo buljili u prazan ekran i pitali se što se događa.

SSD disk se nakon 4-5 godina korištenja pokazao posve ispravnim. Treba tražiti dalje.

Potražimo procese koji usporavaju boot/shutdown. Za to nam može poslužiti systemd, odnosno njegovi alati.

$ systemd-analyze blame
          5.535s NetworkManager-wait-online.service
          1.302s dev-sda6.device
           303ms ModemManager.service
           302ms NetworkManager.service
           301ms accounts-daemon.service
           262ms apparmor.service
           223ms thermald.service
           210ms networking.service
           201ms console-setup.service
           191ms irqbalance.service
           188ms grub-common.service
           169ms systemd-logind.service
           153ms rsyslog.service
           147ms gpu-manager.service
           130ms avahi-daemon.service
           125ms systemd-rfkill.service
           121ms apport.service
           114ms systemd-udev-trigger.service
           107ms lightdm.service
           106ms teamviewerd.service
            92ms systemd-udevd.service
            90ms ondemand.service
            90ms upower.service
            89ms ufw.service
            88ms dev-hugepages.mount
            83ms udisks2.service
            81ms speech-dispatcher.service
            76ms kmod-static-nodes.service
            73ms systemd-modules-load.service
            70ms systemd-journald.service
            61ms systemd-journal-flush.service
            54ms systemd-user-sessions.service
            47ms keyboard-setup.service
            45ms systemd-tmpfiles-setup.service
            35ms pppd-dns.service
            35ms sys-kernel-debug.mount
            35ms alsa-restore.service
            34ms dev-mqueue.mount
            31ms polkitd.service
            31ms systemd-tmpfiles-clean.service
            29ms systemd-random-seed.service
            29ms hddtemp.service
            27ms dns-clean.service

Pri podizanju OS-a najviše vremena troši NetworkManager, zatim inicijalizacija diska. Na trećem mjestu otkrivamo, s čuđenjem, proces modemservice. Modem ne koristimo, čemu se to uopće instalira? Zadnji put mi je modem trebao u hotelu koji nije imao ni bežičnu mrežu ni ethernet priključak u sobi. Bilo je to jako davno.

$ systemctl | grep Modem
ModemManager.service           loaded active running   Modem Manager

Najjednostavnije je rješenje onemogućiti taj servis:

systemctl [stop|start|enable|disable] ModemManager.service

No nije mi dovoljno zaustaviti proces, radije bih deinstalirao paket. Nadam se da neki drugi proces ne ovisi o njemu. Provjerimo:

$ systemctl list-dependencies multi-user.target | grep Modem
● ├─ModemManager.service

Nema međuovisnosti, možemo ga maknuti.

$ sudo apt-get remove modemmanager

Jedan proces manje, brže računalo. Idemo dalje. Za početak tražili smo što usporava boot, ali možemo li pretpostaviti da će isti procesi biti spori i pri shutdownu? Kako vidjeti što se događa kada gasimo računalo?

Današnji desktop Linuxi nalik su na MS Windowse: pokazuju neukom korisniku šarene slikice, ugodne oku, kako ga ne bi, kao što su to nekada radili Uniksoidi, zamarali "nepotrebnim" informacijama. No admini starog kova nostalgični su, rado bi pratili podizanje i spuštanje procesa.

Bombončiće za oči isporučuje paket plymouth. Mogli bismo ga deinstalirati, ali otkrili smo da postoji prečica. Za vrijeme shutdowna pritisnemo tipku ESC, pa ćemo vidjeti retke s informacijama o procesima. Tekst brzo leti ekranom dok je sve u redu, ali ako neki proces zastane, imat ćemo vremena vidjeti što nas usporava.

No zaboravljao sam pritiskati ESC svaki put pri gašenju, pa sam našao temeljitiji, "sistemski" način. Treba malo petljati po konfiguraciji gruba. U datoteci /etc/default/grub zakomentirajte redak u kojem se spominje "quiet splash":

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX_DEFAULT=""

Splash screen je ona šarena sličica koju bi nas trebala hipnotizirati i učiniti zadovoljnima.

Da bi se promjena primila, treba napraviati update gruba.

# sudo update-grub

Mogli smo upisati i ovo:

GRUB_CMDLINE_LINUX_DEFAULT="verbose"

Nekoliko puta reboot, da probam uloviti spori shutdown. Kao za inat, sve prolazi brzo. Stvar je ćudljiva, problemi se događaju povremeno, bez nekog vidljivog uzorka. No jednom prilikom gašenje zastaje pri Network Manageru. Bila je uključena bežična mreža. Da li bi pomoglo da prije gašenja prekinem mrežnu konekciju? Probao sam, ali nema poboljšanja. Međutim, shvatio sam jedno: prije pokretanja shutdowna treba pozatvarati sve aplikacije, izbaciti CD, izvaditi USB stickove - sve to usporava gašenje.

Onda sam u jednoj prilici ulovio zastoj, dok je na ekranu cijelu minutu stajala ovakva poruka:

systemd[1]: Stopping Remote File Systems (Pre).

Uhvatila me paranoja! Kakav udaljeni datotečni sustav? Nisam montirao ništa preko mreže! Jesam li pokupio rootkit koji meni iza leđa održava komunikaciju s nečim na mreži?

Chkrootkit nije našao ništa sumnjivo. To me malo umirilo. Nazad na Google. Nisam jedini kojeg muči sporadičan spor shutdown, na mreži je mnogo rasprava na tu temu. Da skratim priču, evo jedne koja je pomogla. Čini se da je problem u redoslijedu servisa koje systemd zaustavlja pri gašenju. Iz postova na forumima nije bilo posve jasno da li NetworkManager.service treba zaustaviti prije ili nakon dbus.service? Dbus obavlja komunikaciju između aplikacija. Dok je on aktivan, mrežne funkcije od njega očekuju nekakav odgovor koji ne mogu dobiti?

Predloženo rješenje koje je pomoglo jest da u datoteku /lib/systemd/system/NetworkManager.service ispod [Unit] treba upisati

 After=dbus.service

Odmah sam pomislio da će vjerojatno naredni upgrade pregaziti moje izmjene, pa bi to trebalo riješiti "sistemski". No pritisle me obaveze, preči poslovi, pa sam zanemario spor shutdown i proučavanje redoslijeda spuštanja servisa. Kad sam se vratio rješavanju ove zagonetke, već je neki upgrade posložio konfiguraciju kao treba. Čekao sam gotovo mjesec dana da vidim hoće li se spor shutdown vratiti. Nije se ponovio. Shutdown je sada munjevit. Čini se da je nakon pritužbi korisnika Linux zajednica odradila svoje.

Paranoja se pokazala nepotrebnom, uzrok problema je ispao gotovo banalan. Pravi antiklimaks! No nije sve bilo uzalud. Ja sam stara škola, još živim u uvjerenju da je init otac svih procesa. No SysVinit je otišao u zaborav, naslijedio ga je system daemon, koji može podizati servise paraleleno, ne baš sve odjednom, ali svakako uz nekakav paralelizam, što uzbrzava podizanje i gašenje sustava.

NIsam sudjelovao u buntu tradicionalista koji su žalili za initom, ali nisam se baš ni potrudio upoznati systemd. Spor shutdown je probudio moju radoznalost i želju za učenjem. Prvi utisci o system daemonu su dobri, čini se da se tu krije mnogo korisnih mogućnosti. Potrudit ću se da ga bolje upoznam, a to znači da slijedi još poneki članak na tu temu.

U ovoj priči još ima neriješenih zagonetki. Na primjer, zašto je u velikoj većini slučajeva shutdown bio brz, da bi se onda iznenada jako usporio? I kako bi redoslijed gašenja servisa na to utjecao? Problem je nestao zagonetno kao što se i pojavio, to bi nam moglo biti dovoljno. Većina je sistemaca zatrpana prizemnim poslovima i nema dovoljno vremena za neprestano učenje, ali ipak u nama čuči hakerski duh kojii naprosto ne trpi da se nešto ne zna i ne može napraviti.