Forum Debian Users Gang

Kod:

Startup finished in 15.536s (kernel) + 25.735s (userspace) = 41.272s

Jaja sobie robisz?

Ja mam konsolę i pacjenta zalogowanego auutomatycznie na TTY6 po ok 15-18 sekundach, z czego 6-8 sekund Apparmor ładuje moduły.

Gdybym dorzucił managera logowania, to doszłaby jeszcze sekunda, może dwie.

Jak Dagger  pokazywał na forum Gentusia SystemD w akcji, to cała akcja uruchamiania lapka trwała poniżej  7 sekund.
https://forums.gentoo.org/viewtopic-p-6708265.html#6708265
A tutaj jeszcze ciekawszy wynik:
https://forums.gentoo.org/viewtopic-p-6787814.html#6787814

25 sekund na userspace to nawet na SysVinit byłby słabiutki wynik.
Ten szyfrowany dysk też może się montować z 5 sekund, a nie 15.

~40 sekund, to jest "zimny start" Windows Vista. :D

Jak takie studia na SystemD są potrzebne, żeby lapek wstawał 40 sekund, to jest najlepsza reklama SystemD jaką widziałem.  xD

Myślę, ze masz jeszcze ze dwa latka zabawy, żeby SystemD podciągnąć do poziomu obiecywanego przez Lennarta P. xD

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2015-02-08 04:00:26)

Wziąłem się właśnie za testowanie tego odpowiednika crona w systemd. Na pierwszy rzut oka, to wygląda trochę na zbytnią rozrzutność — trzeba tworzyć dwa pliki, .service i .timer, z których drugi z nich aktywuje ten pierwszy. W każdym razie spróbowałem przepisać sobie poniższą linijkę crona:

# m   h  dom   mon   dow   command
30    20    *     *     6  /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /usr/bin/rsync -avx --delete-excluded /home /media/Kabi/sync_home/

W skrócie ma mi syncować katalog domowy o 20:30 w soboty.

W systemd to będzie wyglądać tak:

Plik sync-home.service

[Unit]
Description=Home Sync
Documentation=man:rsync
DefaultDependencies=yes
ConditionDirectoryNotEmpty=/home/morfik/
ConditionPathIsReadWrite=/media/Kabi/sync_home/

[Service]
Type=oneshot
#User=morfik
StandardOutput=null
StandardError=journal
ExecStart=/usr/bin/rsync -avx --delete-excluded /home /media/Kabi/sync_home/
Nice=19
IOSchedulingClass=idle

Tu oczywiście zrezygnowałem z wywoływania nice i ionice i zaprzęgnąłem init do nadania priorytetów. Można także wywołać usługę jako określony użytkownik. Dodatkowo jest też zaprzęgnięty mechanizm sprawdzający obecność i możliwość zapisu/odczytu odpowiednich ścieżek — jeśli któraś z nich zwróci błąd, usługa się nie odpali:

# systemctl status sync-home.service
● sync-home.service - Home Sync
   Loaded: loaded (/etc/systemd/system/sync-home.service; static; vendor preset: enabled)
   Active: inactive (dead) since Sun 2015-02-08 05:30:16 CET; 2min 54s ago
Condition: start condition failed at Sun 2015-02-08 05:32:00 CET; 1min 10s ago
     Docs: man:rsync
Main PID: 49625 (code=exited, status=0/SUCCESS)

Oczywiście można to pominąć ale dobrze jest wiedzieć, że coś takiego istnieje, a samych parametrów Condition* jest ze 20. xD Dodatkowo mam też dodaną kontrolę komunikatów, tak by mi rsync nie syfił logu każdą synchronizowaną ścieżką.

Plik sync-home.timer

[Unit]
Description=Home Sync
Documentation=http://www.freedesktop.org/software/systemd/man/systemd.time.html
Documentation=http://www.freedesktop.org/software/systemd/man/systemd.timer.html

[Timer]
OnCalendar=Sat *-*-* 20:30
Persistent=true
WakeSystem=false

[Install]
WantedBy=timers.target

W przypadku tego pliku, sprawa wygląda już nieco bardziej wymyślnie. Opcja Persistent zapewnia wywołanie usługi w przypadku przegapienia odpowiedniego okna czasowego aktywującego usługę — np. wyłączyliśmy komputer i synchronizacja nie mogła się dokonać. W takim przypadku, po włączeniu pc i załadowaniu się systemu, nastąpi wywołanie tej usługi — ciekawe czy na takiej samej zasadzie działało to w cronie. Opcja WakeSystem ma na celu wybudzenie maszyny jeśli ta jest uśpiona w chwili gdy synchronizacja katalogów miałaby się dokonać. Szkoda tylko, że po dokonaniu operacji nie usypia z powrotem. xD

Jeśli chodzi zaś o konkretną datę wywołania usługi, to można to zrobić na dwa sposoby: przez ustawienie określonej daty (albo jej wzorca) albo wywoływać usługę via OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec= , które raczej mówią same za siebie — jak coś dokładny opis jest w manie. Można stosować także kombinacje. W tym przypadku chcę aby synchronizacja katalogów dokonała się w soboty o 20:30.

Poniżej kilka przykładów:

   Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-* 00:00:00
     Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                   Wed *-1 → Wed *-*-01 00:00:00
           Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
                Wed, 17:48 → Wed *-*-* 17:48:00
Wed-Sat,Tue 12-10-15 1:2:3 → Tue-Sat 2012-10-15 01:02:03
               *-*-7 0:0:0 → *-*-07 00:00:00
                     10-15 → *-10-15 00:00:00
       monday *-12-* 17:00 → Mon *-12-* 17:00:00
 Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45
      12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00
 mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45
            03-05 08:05:40 → *-03-05 08:05:40
                  08:05:40 → *-*-* 08:05:40
                     05:40 → *-*-* 05:40:00
    Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40
          Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40
          2003-03-05 05:40 → 2003-03-05 05:40:00
                2003-03-05 → 2003-03-05 00:00:00
                     03-05 → *-03-05 00:00:00
                    hourly → *-*-* *:00:00
                     daily → *-*-* 00:00:00
                   monthly → *-*-01 00:00:00
                    weekly → Mon *-*-* 00:00:00
                    yearly → *-01-01 00:00:00
                  annually → *-01-01 00:00:00
                     *:2/3 → *-*-* *:02/3:00

Teraz już tylko dodać "budzik" i można sprawdzić jak wyglądają staty zegara:

root:/etc/systemd/system# systemctl list-timers --all
NEXT                         LEFT        LAST                         PASSED       UNIT                         ACTIVATES
Mon 2015-02-09 03:24:03 CET  22h left    Sun 2015-02-08 03:24:03 CET  1h 32min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sat 2015-02-14 20:30:00 CET  6 days left Sun 2015-02-08 04:36:24 CET  20min ago    sync-home.timer              sync-home.service

2 timers listed.

Także jak widać, data następnego syncu jest zaplanowana za 6 dni ale ja nie będę czekał tak długo, by sprawdzić czy to działa jak trza — działa. xD

Przecie to jest katastrofalnie wolno

Jak wywalę Apparmora z usług startowych, to się robi 10 -12 sekund ze startem GDM.
A to już znacznie szybciej, niż u Ciebie.

Dyzio magnetyczny, 7200 obrotów/s.

/dev/sda:
 Timing buffered disk reads: 220 MB in  3.02 seconds =  72.95 MB/sec

Przesadzasz, po prostu Apparmor wczytuje profile dłużej, niż startuje dowolny runlevel, tu jest pies pogrzebany.
Czy go podnoszę w runlvevelu boot czy default, zawsze konsola jest te 6-8 sekund później.

Jeszcze jedna fajna rzecz w OpenRC, której w SystemD nie widziałem:
jak się wysypie OpenRc, to mogę walnąć Sysrq+k, i od razu mam konsolę, i mogę się zalogować do sytemu który jest w takim stanie, do jakiego doprowadzl go OpenRC przed ubiciem.
W SystemD takiej możliwości nie miałem, po ubiciu była czarna konsola.

Przy okazji, z trybu interaktywnego w OpenRC można wyskoczyć prosto na konsolę roota po podaniu hasła.

Także SystemD może kiedyś będzie miał jakiś sensowny poziom, ale idzie to bardzo opornie, bo zamiast robić dobrego i szybkiego intta, to ekipa jest zajęta pożeraniem wszystkich usług Linuxowych, jak np sysloga i dbusa.
Ciekawe kiedy kernel Linux już nie będzie potrzebny, bo zastąpi go SystemD. :D

Z resztą ambicje devów Systemd są dużo większe, chcą nawet zrobić jednego słusznego Linuxa, czyli doprowadzić do momentu, kiedy już nie będą potrzebne dystrybucje Linuxa.

Może z resztą spróbujesz zrozumieć, jakie są plany RHEL, z tego newsa:
http://www.dobreprogramy.pl/Drastyczna-zmiana-struk … ws,57609.html

Niby piękne socjotechniczno-marketoidalne pieprzenie, ale ja jakoś nie widzę miejsca na wolność i swobodę użyszkodników, jeśli uda się, ze wszystkich dystrybucji zrobić jeden, jedynie słuszny system pod wodzą RHEL. :P

Tu masz dyskusję na LWM na ten temat:
http://lwn.net/Articles/610067/

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2015-02-08 07:35:48)

Jacekalex napisał(-a):

Z resztą ambicje devów Systemd są dużo większe, chcą nawet zrobić jednego słusznego Linuxa, czyli doprowadzić do momentu, kiedy już nie będą potrzebne dystrybucje Linuxa.

Może z resztą spróbujesz zrozumieć, jakie są plany RHEL, z tego newsa:
http://www.dobreprogramy.pl/Drastyczna-zmiana-struk … ws,57609.html

Niby piękne socjotechniczno-marketoidalne pieprzenie, ale ja jakoś nie widzę miejsca na wolność i swobodę użyszkodników, jeśli uda się, ze wszystkich dystrybucji zrobić jeden, jedynie słuszny system pod wodzą RHEL. :P

Tu masz dyskusję na LWM na ten temat:
http://lwn.net/Articles/610067/

Pozdro
;-)

To może przeczytaj najpierw tekst źródłowy:

Of course, we are developers of the systemd project. Implementing this scheme is not just a job for the systemd developers. This is a reinvention how distributions work, and hence needs great support from the distributions.

http://0pointer.net/blog/revisiting-how-we-put-toge … -systems.html

Zaśmiecasz kolejny wątek swoimi bajdurzeniami i urojeniami.

Skoro nie znasz się na obsłudze systemd (nie potrafisz nawet uruchomić systemu) i nie chcesz go używać, to po co ujadasz w tym wątku?
Używaj sobie OpenRC w swoim „Gientusiu” i nie uszczęśliwiaj innych na siłę.

@Jacekalex -- http://meetings-archive.debian.net/pub/debian-meeti … Torvalds.webm -- 19min. xD

Ostatnio edytowany przez morfik (2015-02-08 08:23:21)

Tu nie chodzi o analizowanie logów zapisanych, chodzi o to, ze systemd to już ponad połowa dawnych narzędzi działających w przestrzeni roota, który sam loguje swoje zachowanie i zbiera dodatkowo logi innych usług sytemowych.

Jeśli kiedykolwiek w SystemD pojawi się backdoor, to ciekawe, z którego logu się o tym dowiesz. xD
O to, co taka wersja SystemD z backdoorem będzie mogla w systemie zrobić nie pytam, bo to dosyć łatwo zrozumieć, odpowiedź jest oczywista.

Właśnie dlatego wolę, żeby demon syslog był programem autonomicznym, niezależnym od innych elementów systemu, np odpowiedzialnych za autoryzację, kontrolę dostępu albo komunikację między procesami systemowymi.

W przypadku Windows jeden producent robi wszystkie składowe elementy systemu, i nieraz można się przekonać, jakie kłopoty to powoduje,  nie trzeba nawet słuchać Snowdena, żeby wiedzieć, jaka jest podatność Windows na różne diabelstwa i z czego wynika.

A już jedna awantura miedzy developerami Systemd a Linusem T. pokazała,
że oczywistymi błędami się przejmują podobnie, jak ich koledzy po fachu z Redmond.

Pozdro
;-)

Jak CI RHEL wsadzi backdoora do źródeł  SystemD - to zobaczysz na ten temat komunikat w logu, jak prosiak słońce. :D

RED-HAT jest zrośnięty zz amerykańską administracją, jego największym klientem jest rząd USA i podległe mu instytucje, a przypomnij sobie, skąd się wziął backdoor w implementacji Ipsec w OpenBSD wiele lat temu, albo kto i dlaczego wsadził do Openssl drobny kawałek kodu, który spowodował lukę Hearthbleed.

W dodatku, jeśli w systemie Linux, całą przestrzeń roota zajmuje program kontrolowany przez jedną korpo, to diabelnie mało miejsca i swobody  zostaje dla developerów dystrybucji, o użyszkodnikach nie wspominając w ogóle. :P

Ale oczywiście takie drobne niuanse techniczne trzeba rozumieć, dlatego w Gentoo największymi wrogami SystemD są Developerzy projektu hardened. ;)
Dlatego też się nie boję przyszłości w Gentusiu, na 99% "fakesystemd"
z OpenBSD bardzo szybko się w Gentusiu pojawi, jak zawsze w podobnych przypadkach.

Pozdro
;-)

@Yossarian

Podzielisz się linkami do źródeł tych informacji?

https://www.google.pl/#q=red-hat+us+army
https://www.google.pl/#q=red-hat+us+navy
https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

RH chyba nawet od czasów wirusów "I Love You" i "Eva Kurnikova" (sparaliżowały miedzy innymi CIA i NSA) ma praktycznie wyłączność na systemy dla amerykańskiego wojska, marynarki wojennej, NSA, NASA, CIA, FBI, Pentagonu i całego rządu amerykańskiego.
W dodatku zarządza projektami informatycznymi takimi, jak SELINUX, które zostały stworzone w NSA.
Ile kasy RH bierze rocznie  od rządu amerykańskiego?
Ile nieformalnych kontaktów i przyjaźni jest miedzy członkami zarządu RH
a wysokimi urzędnikami "resortów siłowych" USA?
Jaka symbioza i synergia tam występuje?

Równie dobrze mogę podać sznurki stwierdzające, ze w Oceanie Spokojnym jest woda. xD

Oczywiście to są tak wielkie tajemnice, jak fakt, że firmę Kaspersky Lab założył były oficer KGB (która to  informacja zniknęła z Wikipedii kilka dni po rozpoczęciu  aneksji Krymu). :D

Jacekalex napisał(-a):

Jak CI RHEL wsadzi backdoora do źródeł  SystemD - to zobaczysz na ten temat komunikat w logu, jak prosiak słońce. :D

Po co ktoś miałby to robić ?

Jacekalex napisał(-a):

RED-HAT jest zrośnięty zz amerykańską administracją, jego największym klientem jest rząd USA i podległe mu instytucje, a przypomnij sobie, skąd się wziął backdoor w implementacji Ipsec w OpenBSD wiele lat temu, albo kto i dlaczego wsadził do Openssl drobny kawałek kodu, który spowodował lukę Hearthbleed.

Jakieś źródło (link do dokumentu potwierdzającego fakt) potwierdzające Twoje teorie spiskowe posiadasz?

Jacekalex napisał(-a):

Ale oczywiście takie drobne niuanse techniczne trzeba rozumieć, dlatego w Gentoo największymi wrogami SystemD są Developerzy projektu hardened. ;)
Dlatego też się nie boję przyszłości w Gentusiu, na 99% "fakesystemd"
z OpenBSD bardzo szybko się w Gentusiu pojawi, jak zawsze w podobnych przypadkach.

Pomyliłeś fora. Forum dla wróżek to ezoforum.pl. Teksty "I love Gentoo" etc., o raczej na forums.gentoo.org powinny się znajdować.

@yossarian
Tu mamy klasyczny przykład trolowania, nie hejtowania :)

@morfik
Very good job. Fajnie by było jakbyś to wszystko w jakiegoś pdfa ubrał, podpisał i wystawił dla potomnych.

Kiedyś napiszę. xD Póki co zbieram sobie informacje, testuję i spisuję co ważniejsze rzeczy by mi to nigdzie nie uciekło, by mieć w miarę wyrobiony plan o czym pisać w późniejszym czasie.

a systemd podczas satrupozwala załadować jakiś bootsplash?  W sumie to się tak wszystko dzieje że nawet nie wiadomo kiedy login manager wskakuje, ale pytam z czystej ciekawości.