[F15] Kreatorek Do Demonów

[SeeM]

Od czasu nastania gienialnego systemd jedyny znany mi sposób na wyłączanie usług do chkconfig, ale ciężko zapanować nad tym całym bajzlem mając do dyspozycji interfejs tekstowy. chkconfig --list przemilczę, bo najczytelniejszy nie jest.

 

Są jakieś inne możliwości?

[thof]

https://wiki.archlinux.org/index.php/Systemd#Using_systemd

[@WalDo]

https://wiki.archlinux.org/index.php/Systemd#Using_systemd

systemctl stosuje, ale nie da sie ukryc, ze jest on jeszcze bardziej popaprany jesli chodzi o przegladanie i sprawdzanie uslug niz chkconfig.

Nie wspomne o konfiguracji, gdzie pliki konfiguracyjne systemd sa znacznie bardziej skomplikowane niz wiekszosc skryptów startowych init a wyniki uruchomienia uslug przez systemd zaskakujace Np. u mnie serwis akmods wg. systemd

[root@F15 ~]# systemctl status akmods.service

akmods.service - LSB: Builds and install new kmods from akmod packages

Loaded: loaded (/etc/rc.d/init.d/akmods)

Active: failed since Sun, 02 Oct 2011 09:09:06 +0200; 11min ago

Process: 887 ExecStart=/etc/rc.d/init.d/akmods start (code=exited, status=128)

CGroup: name=systemd:/system/akmods.service

podczas startu systemu ostrzegawczo swieci sie na czerwono failed, ale stary poczciwy init mówi co innego

[root@F15 ~]# service akmods start

Checking kmods exist for 2.6.40.4-5.fc15.x86_64 [ OK ]

Sprawdzalem, akmod-nvidia ladnie sie przebudowuje, wiec komu wierzyc?

[thof]

Jak dla mnie to systemd jest duzym krokiem naprzód. Przegladanie i sprawdzanie jest bardzo latwe, przykladowo mozna uzyc status lub systemctl --all | grep cups. Do wyszukiwania mozna uzyc znanego wszystkim find, czyli find /lib/systemd/ /etc/systemd/system -name cups*. Wlasciwie to wszystko mozna zrobic recznie, bo uslugi sa symbolizowane jako dowiazania w folderach (poziomy uruchamiania).

Skrypty konfiguracyjne nie sa wcale skomplikowane, bo najczesciej ograniczaja sie do wywolania programu trybie daemona, czyli linia ExecStart (np. ExecStart=/usr/sbin/crond -n).

 

Akurat u Ciebie to jest akmods, który chyba nie jest zadnym oficjalnym rozwiazaniem wspieranym przez Fedore. Widac, ze spece z rpmfusion zamiast przygotowac skrypt to poszli na latwizne i wywoluja w menedzerze uslug (systemd) kolejnego menedzera uslug (init, czy SysV). W ten sposób to nic dziwnego, ze jest failed. Systemd uruchamiajac usluge oczekuje, ze bedzie sie tak zachowywac, czyli proces dzialajacy bez przerwy w tle, a init po prostu zwraca code=exited, status=128 i konczy zabawe. Prowizoryczne rozwiazanie, bo nikomu nie chcialo sie zmodyfikowac /etc/rc.d/init.d/akmods. Mysle, ze wszystkie oficjalne *.service zachowuja sie juz tak jak nalezy i systemd nie ma problemów z ich obsluga. Po prostu wybrales zly przyklad.

[@WalDo]

Skrypty konfiguracyjne nie sa wcale skomplikowane, bo najczesciej ograniczaja sie do wywolania programu trybie daemona, czyli linia ExecStart (np. ExecStart=/usr/sbin/crond -n).

OK, gorzej jak chcesz zrobic cos bardziej zakreconego. Musisz poznac kolejny jezyk - oczywiscie rozwój itp, ale chociaz czytalem sobie sporo na ten temat, to wciaz nie moge sie dopatrzec w czym systemd jest lepszy od init.

 

[...] poszli na latwizne i wywoluja w menedzerze uslug (systemd) kolejnego menedzera uslug (init, czy SysV).

Nie jestem pewien, ale jesli usluga jest wywolywana w ten sposób, to w czasie startu systemu powinien pojawic sie komunikat z systemd a nastepnie standardowe zakonczenie skryptu init "[ OK ]" albo "[FAILED]" (czyli takie jak pokazalem przy recznym uruchomieniu uslugi).

Oczywiscie zdaje sobie sprawe, ze jestesmy w okresie przejsciowym miedzy init a systemd i wiem, ze jeszcze nie wszystkie uslugi zostaly przepisane.

 

No, ale to chyba temat na dyskusje gdzies w dziale "Offtopic" - sorki za smieci

[thof]

OK, gorzej jak chcesz zrobić coś bardziej zakręconego. Musisz poznać kolejny język - oczywiście rozwój itp, ale chociaż czytałem sobie sporo na ten temat, to wciąż nie mogę się dopatrzeć w czym systemd jest lepszy od init.

Dlaczego? Załóżmy, że chcesz stworzyć sobie swoją usługę, która będzie sprawdzała co jakiś czas czy w folderze pojawiły się jakieś pliki. Możesz to napisać w dowolnym języku C, C++, Pythonie czy Bashu przecież to nie ma znaczenia. Ważne jest, żeby aplikacja miała tryb, który będzie sobie pracował i sam się nie wyłączał. Potem tylko tworzysz plik mojprogram.service z linią ExecStart=/sciezka/program i to wszystko.

Podstawowe zalety systemd to:

systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic

 

Nie jestem pewien, ale jeśli usługa jest wywoływana w ten sposób, to w czasie startu systemu powinien pojawić się komunikat z systemd a następnie standardowe zakończenie skryptu init "[ OK ]" albo "[FAILED]" (czyli takie jak pokazałem przy ręcznym uruchomieniu usługi).

Nie. Wszystkie usługi są puszczane razem (równolegle), wiele z uruchamianych programów coś sobie drukuje. Gdyby pozwolić im na drukowanie komunikaty zaczęłyby się przeplatać. Drukowanie informacji na ekranie zabija wydajność, zwłaszcza przy szybkich dyskach. To co pojawia się w Fedorze to i tak IMO za dużo niepotrzebnych informacji.

Każde samoczynne zakończenie pracy usługi to błąd. Może ją zakończyć jedynie sam systemd poleceniem stop. Z punktu widzenia inita, proces akmods faktycznie działa, ale systemd widzi jedynie wywołanie inita, które zostało zakończone.