Zgiń przepadnij apt-daily.service

Wiadomo co się dzieje z czasem z człowiekiem. Obojętnienie na niektóre bodźce i taki np. start systemu zajmujący niemal dwie minuty nie robi już na nim wrażenia. Czasem jednak nutka odkrywcy buntuje się przed przyjmowaniem świata takim jaki jest. 2 minuty do pełnego pulpitu linuksowego? Bywało przecież lepiej (18 – 24 sekundy). Co zatem poszło nie tak? Namierzenie winowajcy nie było takie trudne.

Poniższe spostrzeżenia mogą dotyczyć większości nowych systemów z rodziny Ubuntu. Wraz z użytkowaniem jednej i tej samej dystrybucji i tego samego środowiska, wydłużanie startu systemu wydaje się być nieuchronne. Sam proces przypomina gotowanie żaby – zaczynając od powolnego podgrzewania (normalny czas startu) dochodzimy do stanu wrzenia (2 minuty). Zarówno żaba jak i użytkownik tego nie zauważą. Do czasu.

Zatem mamy dystrybucję zbudowaną na Ubuntu 16.04 (w moim przypadku Kubuntu). Dystrybucja jak dystrybucja, jednak początkowo długi czas startu systemu można zrzucać na karb rozbudowanej KDE Plasmy. Ale obwinianie środowiska za wszystkie nasze niedopatrzenia jest nieuczciwe. Aby ustalić przyczynę dłuższego startu systemu warto przeprowadzić kilka analiz. Na początku, systemd-analyze blame i czas startu poszczególnych komponentów systemu.

~$ systemd-analyze blame 
         52.971s apt-daily.service
         12.695s ModemManager.service
         11.798s NetworkManager-wait-online.service
          8.555s dev-sda1.device
          4.885s accounts-daemon.service
          3.374s apport.service
          2.614s ondemand.service
          2.266s networking.service
          2.213s gpu-manager.service
          2.096s NetworkManager.service
          2.044s lvm2-monitor.service
          1.758s autofs.service
          1.626s rsyslog.service
          1.556s grub-common.service
          1.463s keyboard-setup.service
          1.412s apparmor.service
          1.175s upower.service
          1.047s systemd-tmpfiles-setup-dev.service
           948ms console-setup.service
           945ms ufw.service
           939ms systemd-udevd.service
           897ms systemd-journald.service
           872ms systemd-modules-load.service
           839ms systemd-rfkill.service
           811ms binfmt-support.service

Co rzuca się nam w oczy? Oczywiście apt-daily.service i 52 sekundy jakie zajmuje tej usłudze doprowadzenie się do stanu funkcjonalności. Deprymująco może działać również 12 sekund jakie pożera ModemManager.service – szczególnie, jeżeli ktoś nie dysponuje połączeniem internetowym korzystającym z takowego.

Usługa apt-daily.service odpowiada za automatyzację kilku procesów związanych z apt. W tym pilnowanie i automatyzowanie aktualizacji. Jeżeli komuś zależy na tych 52 sekundach i potrafi przeprowadzić ręczną aktualizację systemu (uruchomić Menadżera oprogramowania), to z powodzeniem można się tej usługi pozbyć. Należy przy tym pamiętać również o apt-daily.timer, który służy do cyklicznego wywoływania wspomnianego .service. Zatem…

sudo systemctl stop apt-daily.timer
sudo systemctl disable apt-daily.timer
sudo systemctl mask apt-daily.service
sudo systemctl daemon-reload

Polecenie mask tym różni się od disable, że fizycznie podmienia link apt-daily.service i wskazuje nim na /dev/null. Jeżeli komuś gdzieś i kiedyś przyjdzie do głowy jednak aktywować apt-daily.service – to nic z tego.

No dobrze a co z ModemManager.service? Podobnie, jeżeli go nie potrzebujemy (nie korzystamy z wydumanych połączeń bezprzewodowych) to go blokujemy:

sudo systemctl stop modemmanager.service
sudo systemctl disable modemmanager.service

Esteci mogą się oburzyć na takie grubiańskie zarządzanie usługami, ale cóż może zwykły użytkownik w starciu z automatyzacją systemd. Niekiedy poradą jest poprawienie parametrów w /etc/systemd/system.conf i ograniczenie czasu oczekiwania na start usług. We wspomnianym pliku należy zamienić:

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s

… na:

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

Ale co jeśli jakiejś ważnej dla nas usłudze z jakichś przyczyn start zajmie nieco więcej niż 10 sekund? Dlatego jestem zwolennikiem bardziej radykalnych posunięć.

Jak łatwo wyliczyć powyższa zmiana powinna nam dać ponad minutę oszczędności podczas startu systemu. W rzeczywistości udało się faktycznie zejść poniżej minuty podczas startu systemu. Optymalizując start Plasmy i innych komponentów pewnie dałoby się wyciągnąć jeszcze lepszy czas (pamiętajmy, to wszystko na podstarzałym laptopie z dyskiem 7200RPM). Ale to zupełnie inna opowieść.