Tylko zapytam, bo np. pod openrc jest opcja, że skrypt odświeżania repo (haha autoaktualizacji, jak se sam napiszesz:D ) wstanie dopiero w trzecim stadium, kiedy już będzie połączenie z siecią. U niego sieć widać długo wstaje, może wina routera? Nieważne, czy nie da się tego w systemd opóźnić, albo przesunąć priorytetu usługi? Tak sobie tylko myślę…
apt-daily nie blokuje nic (systemctl list-dependencies --reverse apt-daily) więc system nie czeka na jego ukończenie. Dlatego daje to mylne wrażenie, że to jest problem. systemd-analyze blame daje tylko pewien pogląd na temat tego jak długo dany serwis wstaje, ale nie mówi nic o zależnościach między unitami. Warto wyniki interpretować w korelacji z systemd-analyze critical-chain.
Kupić lepszy sprzęt. Obecnie masz fatalny CPU połączony z dyskiem HDD. To nie może działać szybko.
W pewnym sensie się nie zgodzę, dlatego że u mnie z tym procesorem i 2 GB ram arch-linux działa dość płynnie, choć nie można od niego zbyt wiele wymagać.
Po wynikach systemd-analyze blame widać, że wąskim gardłem jest dysk twardy. Usługi powinny startować w ciągu milisekund. W pierwszej kolejności wymiana HDD na SSD.
Nie mówimy tutaj o działaniu tylko o szybkości uruchamiania. Ubuntu pakuje mu snapd, który robi te wszystkie urządzenia loop, odpala rzeczy, których nikt normalnie nie potrzebuje (avahi) i do tego całość jest na paskudnym GNOMIE. Do tego robi rzeczy kompletnie idiotyczne jak fstrim ja dysku HDD. Efekt jest jaki jest.
Avahi to micro-usługa mDNS i wbrew pozorom bywa przydatna w kontekście smart urządzeń (z np. serwerami multimediów) i drukarek Wi-Fi itp. rzeczy w lokalnej sieci.
W każdym razie dziwię się, że Ubuntu stawia tą usługę, ponieważ korzysta z systemd-resolved, która funkcjonalność mDNS ma wbudowaną.
Nawet dokumentacja Arch Linux wspomina, żeby przed uruchomieniem Avahi upewnić się, że mDNS jest wyłączone w resolved.conf lub wyłączyć usługę jako taką całkowicie. ( https://wiki.archlinux.org/index.php/Avahi#Installation )
W porządnej sieci z dobrze skonfigurowanym DNS i DHCP nie ma żadnej potrzeby istnienia tego protokołu. Co więcej, w domowej sieci cały multicast najlepiej wyciąć.