Jak przyspieszyć naprawdę wolne uruchamianie na Ubuntu 16.04?

39

Próbuję zrozumieć, co muszę zrobić, aby przyspieszyć rozruch z Ubuntu 16.04. Mam biegać dmesg i zapisane wyjście tutaj . Wszystko wydaje się nie działać po około 10 sekundach.

boot 16.04 dmesg

— Packwood
źródło

Jeśli spojrzysz na dmesg, możesz znaleźć wpis, taki jak: „nowe opcje montowania nie pasują do istniejącego superbloku”. Jeśli tak, Google dla tego ciągu i doprowadzi cię do błędu w systemie Linux, który nigdy nie został naprawiony

— NickT

Nie sądzę, że widzę ten błąd lub podobny.

— Packwood

Dlaczego czujesz, że coś się psuje po 10 sekundach? Jak myślisz, które przesłanie jest szczególnie niepokojące?

— Ciro Santilli 18 改造中心法轮功六四事件事件

44

Możesz spróbować dowiedzieć się, co zabiera najwięcej czasu systemd

systemd-analyze blame

— użytkownik536489
źródło

31

Tak więc co potem? czy muszę zatrzymać niektóre usługi?

— mohammed amine bourkadi

29

Edycja UUID / etc / fstab przestrzeni wymiany (aby dopasować wynik sudo blkid) działała jak urok!

Uwaga : po tym, jeśli w /etc/crypttabpliku są jakieś pozycje wymiany , należy zmienić jego drugi parametr, aby pasował do przestrzeni wymiany, albo według UUID lub ścieżki (tj. UUID = coś lub / path / to / swap).

Na moim dysku SSD bootowanie trwało od 2 minut do mniej niż 10 sekund.

Chodzi o to, że właśnie zrobiłem normalną aktualizację z 14.04 do 16.04, bez bałaganu w partycjach, gdy ten problem się zaczął. Oczywiście istnieją pewne problemy z procedurą aktualizacji.

— M Dub
źródło

Dziękuję, że bardzo mi pomogło: na potrzeby testu umieściłem swap na wymiennym caddy, nie ma problemu z uruchomieniem, gdy dysku nie było 14.04, przy 16.04 rozruch zajął 1 lub 2 minuty dłużej. Wygląda na to, że jądro 3 było szybsze niż jądro 4, gdy nie znalazło wymiany.

— Emmanuel,

Dzięki. uratowałeś mi dużo czasu. Aktualizowałem także system z 14.04, więc ten problem wystąpił.

— PaladiN,

Dzięki, miałem ten sam problem z niepoprawnym UUID wymiany, kiedy zmieniłem go na blkid, zajęło mu to około 60 sekund do zaledwie 5 sekund

— Brandon Søren Culley

2

Zajrzyj do askubuntu.com/questions/38533/... odpowiedzi, aby uzyskać więcej informacji o tym, jak to zrobić. Skróciło mój czas uruchamiania ze 100+ sekund do 15.

— Dmitry

tak, zaktualizuj do wersji 17.10, ale mój zamiany uuid pasuje do wyniku z „blkid”

— Vasil Valchev

10

Mam podobny problem z dłuższym czasem uruchamiania po aktualizacji.

W czym był problem? Usunąłem przestrzeń wymiany, więc mój plik / etc / fstab i nowy system plików miały konflikty. Program ładujący czekał na znalezienie prawie 1m 30s.

Jak rozwiązałem problem Uruchom sudo blkid

Otwórz plik / etc / fstab i porównaj dopasowanie UUID z posiadanymi partycjami. Jeśli występuje niezgodność, zmień to i uruchom ponownie.

— Gokul Palwe
źródło

Wynik dmesgw pytaniu pokazuje, że OP ma inny problem.

— Bajt Dowódca

9

Jest to rozwiązanie obejścia, ale znacznie skróciło czas uruchamiania (z 1 min 24s do 16s).

sudo vim /etc/systemd/system.conf

Odkomentuj te dwa parametry i ustaw żądany limit czasu:

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

Uwaga: Zoptymalizuj te wartości, aby dopasować je do swoich potrzeb sprzętowych ~ 5 - 60s.

Jak omówiono tutaj te parametry skonfigurować domyślne limity czasu uruchamiania i zatrzymywania jednostek, a także domyślny czas do snu między automatycznych restartów jednostek, jak skonfigurowany na jednostkę w TimeoutStartSec=, TimeoutStopSec=i RestartSec=(dla usług, patrz systemd.service (5) szczegółowe informacje na temat ustawień poszczególnych jednostek).

W przypadku jednostek nieobsługiwanych DefaultTimeoutStartSec=ustawia wartość domyślną TimeoutSec= value. DefaultTimeoutStartSec=i DefaultTimeoutStopSec=domyślnie do lat 90. DefaultRestartSec=domyślnie 100ms.

Edytuj - bardziej szczegółowo:

Przeanalizowałem sekwencję rozruchu systemd-analyze plot > sequence.svg, pokazując, że usługi nie uruchamiają się w moim świeżo zaktualizowanym systemie operacyjnym. Były trzy - jeden był źle skonfigurowanym demonem sendmaila, a następnie powerd.service & NetworkManager-wait-online.service . Ponieważ całkowite wyłączenie usługi NetworkManager nie jest dobrym pomysłem, po prostu pozostawiłem jej limit czasu po 10 sekundach i zastosowałem tę regułę globalnie.

— Mirek
źródło

2

Czy możesz rozwinąć sposób, w jaki to rozwiązanie skróciło czas uruchamiania o 68 sekund?

— Elder Geek

Żadnych prób, ciesz się!

— Mirek

nie działa dla mnie, ponieważ po zastosowaniu zmian mój czas rozruchu skrócił się z 52 do 57 sekund.

— Woeitg,

1

10s jest za niski. Może uruchomić system w tryb odzyskiwania. Używam 30s

— Anwar

10s zepsuło mi bootowanie w 18.04. Teraz naprawiam Ubuntu w trybie odzyskiwania.

— Pasupathi

1

Może to być związane z problemami z systemem plików. Możesz sprawdzić ten link, aby sprawdzić, czy naprawa systemu plików skraca czas uruchamiania: https://help.ubuntu.com/community/Filesystem

— Chris J Arges
źródło

Hmm teraz wydaje się być [dłuższy!] ( pastebin.com/a5g4wHvA ) Wygląda na to, że nie działa po około 30 sekundach. „eth0: link nie jest gotowy” „nf_conntrack: automatyczne przypisywanie pomocnika jest przestarzałe i zostanie wkrótce usunięte. Użyj celu CT iptables, aby dołączyć pomocników zamiast”

— Packwood

0

Miałem podobny problem, który właśnie rozwiązałem: uruchamiam Ubuntu 16.04 na dysku SSD. Używam dysku flash jako partycji wymiany. Dysk został przypadkowo nieznacznie przesunięty i uruchomienie zajęło ponad 3 minuty. Odłożyłem to poprawnie i teraz wszystko jest w porządku. Jeśli wypróbowałeś smartctl lub fsck i twój system plików jest w porządku, spróbuj usunąć dyski flash (lub inne urządzenia peryferyjne?) I zobacz, jak to działa. Powodzenia!

— joham34
źródło

0

Na podstawie twoich wyników pastebin wyskakuje na mnie kilka rzeczy:

EXT4-fs (sda5): re-mounted

Może chcesz fsck tę objętość i przyjrzeć Smart Data na tym dysku.

i

[   31.022220] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   45.720952] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   45.761548] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

Możesz spróbować wyłączyć IPV6 w połączeniach sieciowych, jeśli twoje połączenie go nie obsługuje.

— Starszy Geek
źródło

0

Zgodnie ze wskazówką user536489:

systemd-zanalizuj winę

Sprawdź, czy jest usługa, której uruchomienie trwa długo, i ustaw niższy limit czasu:

sudo vim /lib/systemd/system/networking.service

Zmień TimeoutStartSecna coś takiego 10s. Stan strony podręcznika przyjmuje wartość bez jednostki w sekundach lub wartość przedziału czasu, na przykład „5min 20s”. Przekaż „nieskończoność”, aby wyłączyć logikę limitu czasu.

— max
źródło