[SOLVED] Opcje startu systemu

[Robert75]

Jak nie jest związane z tematem, mi się zdaję że jednak jest. Kolega @paranoise ma problem z szybkością startu systemu, to skoro ten pakiet o nazwie plymouth wydłuża start systemu, to Mógłbyś nam wyjaśnić, jak prawidłowo odinstalować plymouth.

Arch Linux Xfce - 64Bit Linux User #621110

[pavbaranov]

@Robert75: „5. Obowiązuje zasada – Jeden temat, jeden wątek. Zakładając wątek postaraj się podać jak najwięcej informacji dotyczących problemu. Prosimy nie pisać posta pod postem – prosimy używać przycisku ”Edytuj”. Czas na edycję posta to 24 godziny.” Pkt 5
Pomijając wszystko nawet nie wiadomo, czy zakładający wątek ma problem z odinstalowaniem plymouth – to jest Twój problem.

[paranoise]

Przepraszam, że dopiero teraz, ale w międzyczasie miałem spore problemy z uruchomieniem w ogóle systemu. Oto log z „systemd-analyze blame”:

          8.197s systemd-journald.service
          5.499s dev-sda2.device
          3.808s plymouth-start.service
          2.754s ModemManager.service
          1.352s NetworkManager.service
           913ms tmp.mount
           912ms dev-mqueue.mount
           912ms dev-hugepages.mount
           911ms sys-kernel-debug.mount
           859ms systemd-remount-fs.service
           765ms systemd-journal-flush.service
           725ms lightdm-plymouth.service
           723ms plymouth-quit-wait.service
           713ms sys-kernel-config.mount
           710ms systemd-logind.service
           691ms systemd-rfkill.service
           674ms polkit.service
           674ms systemd-user-sessions.service
           634ms upower.service
           500ms udisks2.service
           431ms accounts-daemon.service
           397ms systemd-tmpfiles-setup-dev.service
           393ms bluetooth.service

Tutaj zaś z „systemd-analyze critical-chain”:

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.

graphical.target @14.357s
└─lightdm-plymouth.service @13.631s +725ms
  └─systemd-user-sessions.service @12.955s +674ms
    └─nss-user-lookup.target @13.920s

[pavbaranov]

Oki – nieszczęsny plymouth ;)
Teoretycznie on zabiera ok. 14 sek (w podanym przykładzie, ale to do uruchomienia się grafiki). Niemniej jednak i tak, w jego czasie winny być wykonywane jakieś usługi, stąd też nie jest to jeszcze miarodajne.
Biorąc pod uwagę czasy podane z blame dla mnie dziwnym jest aż tak długi czas uruchamiania się dziennika, zwłaszcza na nowo postawionym systemie.
Apetyt journalctl bardzo prosto można ukrócić, zmieniając domyślną wartość przestrzeni jaką systemd sobie na niego życzy. Możemy to zrobić edytując plik /etc/systemd/journald.conf i zmienić w nim wartość SystemMaxUse= dostosowując do swoich preferencji. Pamiętajmy o usunięciu „#” sprzed linijki. Standardowo w archowych systemach domyślna wartość to 10% partycji, na której znajduje się dziennik, a nie więcej niż 4GB. Zwłaszcza po dłuższym czasie, gdy zapełni się ów dziennik, jego „obróbka” zajmie systemowi więcej czasu. Znów – wybór należy do Was. Sami sobie musicie odpowiedzieć na pytanie, czy potrzebny jest Wam tak duży plik dziennika, czy też mniejszy. Wielkość parametru podajemy w XM, gdzie X to cyfra wskazująca na wielkość pliku (limi), a M to MB.

Plymouth i to 14 sek. Prawdopodobnie podnoszenie „graphical target” w takim czasie związane jest z używaniem sterowników nvidia (lub układów Intel+NVidia), które znane są z tego, że ich podnoszenie się jest długie. Niemniej jednak potem otrzymujemy dość dobrą wydajność kart NVidia (w porównaniu z nouveau na pewno). Coś zatem za coś. Podobnie podnoszenie układów Intel/NVidia jest dłuższe niż każdego z nich z osobna. Nie, nie potrafię powiedzieć co to powoduje, nie mam takiego układu, ani też samego GPU NVidii. Po prostu zauważyłem, że start systemu z takimi sterownikami jest dłuższy. Jeśli chcecie poszukajcie we własnym zakresie czy coś tu można zmienić. Ja nawet – z ww. przywołanych powodów – nie mam tego jak sprawdzić.
Sam plymouth można wyłączyć, choć wiele chyba tu nie uzyskamy. Na pewno będzie „brzydziej”, bo system zostanie pozbawiony ładnego ekranu startowego. Znów zatem – wybór należy do Was. Proces instalacji i konfiguracji plymouth jest opisany w wiki Archa. By „odinstalować”, a przynajmniej zrezygnować z niego nie wystarczy odinstalowanie paczki, albowiem takie działanie nic nie da i najczęściej po restarcie zobaczycie czarny ekran. Musicie jescze przeładować obraz kernela (owe polecenie rozpoczynające się od mkinitcpio, odpowiednio usuwając z pliku /etc/mkinitcpio.conf wpisy odnoszące się do plymouth, jak również pamiętać o usunięciu splash z linii komend kernela. Osobiście zalecałbym również przeładowanie GRUB (jeśli jego używacie).

Następna kwestia – podnoszona jest usługa ModemManager. Jest ona potrzebna wyłącznie, gdy korzystamy z tzw. modemu komórkowego. Przy czym sens jej uruchamiania przy starcie jest wyłącznie wówczas, jeśli takie połączenie chcemy uzyskać za każdym razem. Jeśli z połączenia tego typu korzystamy sporadycznie (w terenie), to sensowniej usługę taką usunąć, a wywoływać ją przed połączeniem komórkowym.
Na zmniejszenie zapotrzebowania dev-sda2 na czas potrzebny do jego podniesienia nie mam żadnego pomysłu. Zauważyłem jedynie, że czasy te są różne (generalnie podnoszenie się systemu nie jest w 100% powtarzalne – sprawdźcie sobie). Oczywiście jest też zależne od tego z jakim rodzajem dysku (partycji) mamy do czynienia.

I to tak co mi się nasuwa. A teraz kubeł zimnej wody. UWAGA jeśli ktoś nie bardzo wie, orientuje co dokładnie robi, czy robi to poprawnie, oraz – może nawet przede wszystkim – czy wie jak reanimować system, który po zabawie z usługami nie wstał, to lepiej niech się tym nie bawi i pozostawi je tak, jak są. Akurat w Manjaro nie zabierają one aż tak wiele czasu i system wstaje w miarę sprawnie. To Wasza decyzja, czy grzebać w usługach, by system startował powiedzmy 10 sek szybciej (u mnie to na dopiero wstępnie zoptymalizowanym systemie wygląda obecnie tak: Startup finished in 6.610s (kernel) + 4.254s (userspace) = 10.864s
), ale grozi to nawet wielogodzinnym naprawianiem systemu (zwłaszcza, gdy się na tym ktoś nie zna), czy też pozostawić jak jest. Pamiętajcie też o jednym: jeśli coś z usługami robicie i jeśli nie do końca wiecie co, to należy zapisywać sobie gdzieś z boku co się dokonało, a w razie problemów informacje takie podać nam. Nikt bowiem nie ma bezpośredniego dostępu do Waszych systemów, nikt nie wie co dokładnie zostało w nich zmienione. Ewentualna pomoc jest zatem mocno ograniczona i co najmniej w części polega na zgadywaniu.

[Robert75]

Znalazłem sposób aby ten nieszczęsny plymounth przyśpieszył podczas uruchamiania systemu. Po prostu uśpiłem system, muszę przyznać że zrobiłem to przez przypadek ale efekty są zauważalne oto mój wynik:

[robson@amd ~]$ systemd-analyze
Startup finished in 3.876s (kernel) + 15.999s (userspace) = 19.876s
[robson@amd ~]$ systemd-analyze critical-chain
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.

graphical.target @15.675s
└─lightdm.service @14.976s +699ms
  └─systemd-user-sessions.service @14.424s +17ms
    └─nss-user-lookup.target @15.050s
[robson@amd ~]$ systemd-analyze blame
         11.775s plymouth-start.service
          7.522s systemd-journal-flush.service
          3.684s plymouth-read-write.service
          3.535s systemd-journald.service
          2.914s dev-sda7.device
          1.941s pamac.service
          1.427s ModemManager.service
          1.034s colord.service
          1.022s tlp.service
          1.001s NetworkManager.service
           818ms systemd-modules-load.service
           749ms ntpd.service
           729ms dev-disk-by\x2duuid-9800a0f8\x2d976e\x2d4263\x2db538\x2df4e9e65
           711ms polkit.service
           699ms lightdm.service
           610ms systemd-tmpfiles-setup-dev.service
           530ms plymouth-quit.service
           528ms plymouth-quit-wait.service
           498ms systemd-udevd.service
           430ms dev-disk-by\x2duuid-ed85a898\x2d1b87\x2d49d9\x2dba46\x2d8059d31
           304ms udisks2.service
           271ms accounts-daemon.service
           265ms systemd-tmpfiles-clean.service
lines 1-23

Stosuj poprawnie code. Poprawiłem. Aquila

Arch Linux Xfce - 64Bit Linux User #621110

[pavbaranov]

To nie jest sposób na plymouth – po prostu uruchomieniu systemu po uśpieniu on Ci się w ogóle nie powinien uruchamiać.

[Robert75]

Ale ważne że pomogło. Dzisiaj przy pierwszym uruchomieniu systemu oto wynik: `robson@amd ~]$ systemd-analyze
Startup finished in 3.876s (kernel) + 15.999s (userspace) = 19.876s

Arch Linux Xfce - 64Bit Linux User #621110

[pavbaranov]

Przy pierwszym uruchomieniu, czy przy „przebudzeniu” z uśpienia?
W pierwszym przypadku – całkiem znośny wynik. Przy drugim… raczej słabo.

[Robert75]

Tzn.uśpiłem go wczoraj następnie zrestartowałem, a przy dzisiejszym pierwszym uruchomieniu wynik jak powyżej.

Arch Linux Xfce - 64Bit Linux User #621110

[pavbaranov]

Czyli z tzw. cold start? To jest on na HDD w normie jak na Manjaro. W przypadku SSD – to bardzo słaby wynik.

[Robert75]

Oczywiście że na HDD.

Arch Linux Xfce - 64Bit Linux User #621110

[aquila]

Widzę, że ta dyskusja prowadzi donikąd. Zamykam.

Ps. @robert75 zobacz i przeanalizuj jaki popełniasz błąd z code

Bad Tux | Spacja przed "?" | Aquila

[Autor]

Posty