Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Poradnik: systemd — cz. 1

Moim celem jest stworzenie PRAKTYCZNEGO podręcznika skierowanego do administratorów.

Wstęp

Uwagi na temat użytego języka:
  • nie chcę tłumaczyć angielskich nazw własnych na język polski, bo nie pomaga to w zrozumieniu przedmiotu
  • jest to tekst skierowany do adminów, którzy na co dzień czytają dokumentacje po angielsku - oni mi wybaczą
  • czy to jest normalne aby angielskie słowa odmieniać przez polskie przypadki - niestety tak :)

Co to jest systemd?

  • wikipedia
  • menadżer systemu i usług
  • zastępuje rozwiązania takie jak: SysVinit, upstart
  • podstawową jednostką organizacyjną jest "unit"
  • w unitach można zdefiniować zależności między nimi

Mówiąć o systemach Unix/Linux zwykło się twierdzić, że "wszystko jest plikiem". Myśląc o systemd możemy myśleć, że "wszystko jest unitem".

Skąd się biorą te unity?

  • z pakietów/paczek (rpm, deb, ...)
  • unity mogą być utworzone/modyfikowane przez administratora
  • unity mogą być utworzone/modyfikowane przez użytkowników
  • unity również generowane są dynamicznie (generatory)

Jakie dystrybucje używają systemd?

Praktycznie większość: Arch Linux, Fedora, Debian, Ubuntu itd. W opozycji do nich trwają: Gentoo i Slackware. Systemd jest obecny w dwóch najważniejszych dystrybucjach klasy "enterprise": RHEL7 i SLES12.

Notacja

Jeśli używam nawiasów '[opcja]' znaczy, opcja ta może ale nie musi występować - jest opcjonalna. Czyli w poniższym poleceniu # systemctl [list-units] mogę, ale nie muszę użyć opcji "list-units".

Jeśli używam '{opcja_1|opcja_2|opcja_3}', to dokładnie jedna ze zbioru opcji MUSI wystąpić. Czyli w poniższym poleceniu # systemd-tmpfiles {--clean|--create|--remove} /path/to/filename.conf oznacza, że musisz użyć jednej z opcji: "--clean", "--create", "--remove": # systemd-tmpfiles --clean /path/to/filename.conf # systemd-tmpfiles --create /path/to/filename.conf # systemd-tmpfiles --remove /path/to/filename.conf

Wersje

Różne wersje systemd w różnych dystrybucjach, czyli różna funkcjonalność.
Wersje serwerowe (RHEL7, SLES12) zawierają starsze wersje i pewnie część funkcjonalności, omawiana w tym poradniku, będzie niedostępna. W dystrybucjach bardziej "desktopowych": Arch Linux, Fedora - systemd powinien być bardziej na czasie...

Źródła

Lennart Poettering Blog

freedesktop.org

Arch Linux Wiki

Digital Ocean

YouTube

Structural and semantic deficiencies in the systemd architecture for r...

A history of modern init systems (1992-2015)

Unity

Wszystkie procesy działające w systemie są procesami potomnymi "systemd init process". (PID=1) $ ps -q 1 -o pid,comm,command PID COMMAND COMMAND 1 systemd /sbin/init Ten fakt ma duże znaczenie dla administratorów, gdyż działanie całego systemu zależy od tego, jak działa systemd.

Wstęp

Lokalizacje: (man systemd.unit) /etc/systemd/system/* /run/systemd/system/* /usr/lib/systemd/system/* $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* /etc/systemd/user/* /run/systemd/user/* /usr/lib/systemd/user/*

  • pliki konfiguracyjne unitów "systemowych" - pochodzące z pakietów instalacyjnych - znajdują się tu: /usr/lib/systemd/system/
  • jeśli chcesz zmodyfikować unit z /usr/lib/systemd/system/, to ... zostaw go w spokoju. Zamiast tego utwórz nowy w /etc/systemd/system/
  • jeśli chcesz utworzyć własny "systemowy" unit, umieść go tu: /etc/systemd/system/
  • konfiguracja globalna użytkowników (pochodząca z pakietów): /usr/lib/systemd/user/
  • konfiguracja globalna użytkowników (modyfikacja tych z pakietów i własna twórczość): /etc/systemd/user/
  • konfiguracja indywidualna użytkownika: $HOME/.config/systemd/user/

Nie modyfikuj plików unitów z /usr.

Zawsze plik unitu z /etc ma pierwszeństwo przed tym z /usr.

Rodzaje unitów

  1. timer - aktywacja zadań oparta o czas (man systemd.timer)
  2. service - coś jak "stare" serwisy/usługi (man systemd.service)
  3. socket - nasłuchiwanie na danym porcie zamiast uruchamianie serwisu. Usługa zostanie uruchomiona po podłączeniu się klienta - coś jak "xinetd"
  4. target - trochę, jak runlevele, ale tylko trochę (man systemd.target). Target grupuje unity w logiczną funkcjonalność; można aktywować wiele targetów w tym samym czasie, ale jeden ustawiamy jako domyślny.
  5. path - monitorowanie ścieżki w celu aktywacji jakiegoś zadania (man systemd.path)
  6. scope - grupa procesów. Sesje użytkowników, kontenery, wirtualne maszyny są pogrupowanie w "scope'y" (man systemd.scope)
  7. slice - hierarchicznie pogrupowane unity "scope" i "service" (man systemd.slice). Jest to sposób na "partycjonowanie" dostępnych zasobów. Domyślnie cały system ("root slice") jest podzielony na trzy partycje:
    • system (usługi systemowe)
    • machine (maszyny wirtualne i kontenery)
    • user (sesje użytkowników)
  8. automount - auto montowanie filesystemów (man systemd.automount) takich jak: /proc i /sys
  9. mount - montowanie filesystemów (man systemd.mount) takich jak: /boot, swap, /tmp
  10. snapshot - snapshoty nie są konfigurowane przez pliki. Są dynamicznie (systemctl snapshot) zapisywanym stanem procesów. (man systemd.snapshot)
  11. device - pliki urządzeń (man systemd.device)
  12. busname - (tylko gdy system używa "kdbus" ten typ ma zastosowanie) Kdbus ma w przyszłości zastąpić D-Bus. Systemd ma generator, który na podstawie klasycznej aktywacji szyny dbus1 generuje unitu typu "service" i "busname". Serwis "busname" działa "podobnie" jak "socket" - czeka na próbę aktywacji szyny "po nazwie" i uruchamia usługę "service", przypisaną do tej szyny.

Service / Podstawowe polecenia

Na przykładzie unitów typu "service" - usług/serwisów - poznamy podstawowe polecenia przydatne w codziennej pracy administratora.

Wylistowanie typów unitów:# systemctl -t help"Standardowe" opcje unitów (trochę jak stare polecenie "service"):# systemctl {start|stop|status|restart|reload} name.typePermanentne włączanie i wyłączanie - trochę podobne do "chkconfig on/off":# systemctl {enable|disable} name.typeKombinacja disable-enable:# systemctl reenable name.type

Domyślny typ unitu, to "service".
Zatem dwa poniższe polecenia są równoważne: # systemctl start sshd.service # systemctl start sshd

Sprawdzenie statusu unitu: # systemctl status sshd * sshd.service - OpenSSH Daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2015-10-01 14:17:59 CEST; 1min 12s ago Main PID: 29299 (sshd) CGroup: /system.slice/sshd.service `-29299 /usr/bin/sshd -D Oct 01 14:17:59 archer.local systemd[1]: Started OpenSSH Daemon. Oct 01 14:17:59 archer.local sshd[29299]: Server listening on 0.0.0.0 port 22. Oct 01 14:17:59 archer.local sshd[29299]: Server listening on :: port 22. Oct 01 14:18:33 archer.local systemd[1]: Started OpenSSH Daemon.

"Loaded":

  • loaded - plik unitu znaleziony i używany- dodatkowo: plik źródłowy unitu, stan po restarcie (enable/disable/static), predefiniowany stan po restarcie (enable/disable)
  • not-found - pliku unitu nie znaleziono
"Static" znaczy, że unit może być uruchomiony - w uproszczeniu - przez system i nie może być uruchomiony "ręcznie" przez administratora. Stan predefiniowany, czyli domyślny stan po instalacji pakietu z oprogramowaniem.

"Active":

  • active - działa
    • running - proces jest uruchomiony
    • exited - zakończony sukcesem
    • waiting - czeka na "event"
  • inactive(dead) - nie działa, pytanie: dlaczego :)

Sprawdzenie statusu unitu, podając PID procesu lub jednego z procesów potomnych:# systemctl status PIDZapytanie "czy wystartowano", "czy włączono" daną usługę/unit: # systemctl is-active name.type # systemctl is-enable name.type Wylistowanie załadowanych unitów:# systemctl [list-units]Wylistowanie wszystkich unitów (także tych wynikających z zależności, ale niezainstalowanych):# systemctl [list-units] --allWylistownie załadowanych serwisów: # systemctl [list-units] --type=service # systemctl [list-units] -t service Wylistowanie wszystkich serwisów (również tych, są zdefiniowane jako zależności między unitami, a nie są zainstalowane lub zdefiniowane):# systemctl [list-units] -t service --allWylistowanie niepoprawnie działających unitów: # systemctl --failed # systemctl --all --failed # systemctl --all --type=error # systemctl --all --type=not-found Wylistowanie wszystkich "trefnych" unitów:# systemctl --all --failed --type=error --type=not-found --no-legendWylistowanie załadowanych unitów jednego, konkretnego typu:# systemctl -t {service|socket|busname|target|snapshot|device|mount|automount|swap|timer|path|slice|scope}

Jeśli zmienimy konfiguracja unitów (zawartość plików unitów, ale również plików konfiguracyjnych takich jak: /etc/fstab, na podstawie których systemd generuje unity), to należy poinformować o tym systemd:# systemctl daemon-reloadPermanentne wyłączenie unitu (głównie serwisów): (mocniejsze niż "disable", bo ani ręcznie, ani jako zależność unit ten nie zostanie uruchomiony):# systemctl mask name.typeWyłączenie "maskowania":# systemctl unmask name.typeWylistowanie zamaskowanych unitów:# systemctl list-unit-files | awk '$2 == "masked" {print $1}'

Wylistowanie wszystkich plików unitów (trochę podobne do "chkconfig --list"): # systemctl list-unit-files --all UNIT FILE STATE (...) user.slice static avahi-daemon.socket enabled dbus.socket static dm-event.socket static docker.socket enabled git-daemon.socket disabled krb5-kpropd.socket disabled libvirtd.socket enabled lircd.socket disabled lvm2-lvmetad.socket static (...) "State":

  • enabled - włączony, po restarcie systemu zostanie włączony
  • disabled- wyłączony, po restarcie systemu nie zostanie włączony, chyba że inny unit tego wymaga...
  • static- może być uruchomiony, jeśli wymaga tego inny unit, ale nie może być uruchomiony przez administratora lub użytkownika
  • masked- wyłączony permanentnie

Wylistowanie unitów wymaganych przez dany unit:# systemctl list-dependencies name.type

Wymuszenie zatrzymania unitu, który "zawisł" ( i/lub ExecStop= nie działa ). Możemy wysłać do wszystkich procesów sygnał:# systemctl kill [-s [SIG]KILL] [--kill-who=username] name.type

No ale jak taki unit typu "service" wygląda od środka?
Najprostszy wygląda tak: [Service] ExecStart=/path/to/application

"Prawdziwy" serwis wygląda tak (sshd.service): [Unit] Description=OpenSSH Daemon Wants=sshdgenkeys.service After=sshdgenkeys.service After=network.target [Service] ExecStart=/usr/bin/sshd -D ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=always [Install] WantedBy=multi-user.target W wielkim skrócie:

  • Sekcja [Unit] opisuje meta informacje i zależności
  • Sekcja [Service] opisuje co i jak ma być uruchomione
  • Sekcja [Install] opisuje do jakiego targetu będzie dołączona ta usługa po jej włączeniu

Więcej powiemy na ten temat w rozdziale poświęconym tworzeniu własnych unitów.

Target

Target, czyli pewna funkcjonalność zdefiniowana przez grupę usług i innych targetów.
Podczas uruchamiania systemu celem jest "osiągnięcie" domyślnego targetu.
Nie mylić targetu z "runlevelem".

Jaki jest domyślny target?# systemctl get-defaultJak zmienić domyślny target?# systemctl set-default name.target

Lista wszystkich targetów: # systemctl --all -t target

Wylistowanie targetów wymaganych przez konkretny target: # systemctl list-dependencies multi-user.target | grep '.target$' multi-user.target +-basic.target | +-paths.target | +-slices.target | +-sockets.target | +-sysinit.target | | +-cryptsetup.target | | +-local-fs.target | | +-swap.target | +-timers.target +-getty.target +-remote-fs.target

Kiedyś w dystrybucjach z rodziny RHEL/Fedora "runlevel 3" oznaczał, że serwer jest w pełni funkcjonalny, a "runlevel 5" dodatkowo miał włączone środowisko graficzne.
Domyślny "runlevel" określony był w pliku /etc/inittab. Obecnie podobną funkcjonalność można uzyskać ustawiając domyślny target, albo na "multi-user.target", albo na "graphical.target".

Zmiana "stanu" systemu jest możliwa poprzez włączenie/wyłączenia "targetu".

Aby wystartować system w innym targecie niż domyślny, ustaw zmienną "systemd.unit=" w programie ładującym (grub, grub2, lilo,...) podczas uruchamiania systemu.

Wymuszenie osiągnięcia domyślnego targetu: # systemctl default # systemctl isolate default.target Target "rescue" przydaje się do naprawy systemu i można go wymusić przy starcie systemu. Jego celem jest załadowanie minimalnego zestawu usług: # systemctl rescue # systemctl isolate rescue.target Target "emergency" również służy głównie do naprawy systemu i można go wymusić przy starcie systemu. Po załadowaniu jądra i jego "ramdysku" wyszukana zostaje partycja główna "/" i zamontowana w trybie "tylko do odczytu". Na tym etapie przejmujemy kontrolę nad systemem: # systemctl emergency # systemctl isolate emergency.target Przygotowanie systemu do wyłączenia zasilania: # systemctl halt # systemctl start halt.target --irreversible [--force [--force]] Wyłączenie systemu razem z zasilaniem: # systemctl poweroff # systemctl start poweroff.target --irreversible [--force [--force]] Restart systemu: # systemctl reboot # systemctl start reboot.target --irreversible [--force] "Usypianie": # systemctl suspend # systemctl start suspend.target "Hibernacja": # systemctl hibernate # systemctl start hibernate.target Połączenie "usypiania" z "hibernacją": # systemctl hybrid-sleep # systemctl start hybrid-sleep.target

Socket

Pytanie: Czy aplikacja (sieciowa) musi być uruchomiona przy starcie, czy też dopiero wtedy, kiedy jest potrzebna?

Oto sshd.socket: [Unit] Description=SSH Socket for Per-Connection Servers [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target

Domyślnie "socket" uruchamia "service" o tej samej nazwie.

Teraz zamiast używać sshd.service możemy użyć sshd.socket: # systemctl stop sshd # systemctl disable sshd # systemctl enable sshd.socket # systemctl start sshd.socket

Od tej chwili to systemd nasłuchuje na porcie :22 w oczekiwaniu na połączenie.
(Tak naprawdę to sshd.socket nie uruchomi bezpośrednio usługi sshd.service, tylko "template" sshd@.service - wszystko przez opcję "Accept=yes" - o "template'ach" będzie później...)

Timer

Timer jest odpowiedzialny za uruchomienie usługi w określonym czasie lub/i o określonym interwale.

Domyślnie "timer" uruchamia "service" o tej samej nazwie.

Przykładowo: # cat /usr/lib/systemd/system/systemd-tmpfiles-clean.timer (...) [Timer] OnBootSec=15min OnUnitActiveSec=1d Timer systemd-tmpfiles-clean.timer uruchamia usługę systemd-tmpfiles-clean.service:
- 15 minut po uruchomieniu serwera
- po pierwszym uruchomieniu cyklicznie co jedną dobę

Inne przydatne opcje:

  • OnActiveSec= - od momentu aktywacji timera
  • OnBootSec= - od uruchomienia serwera
  • OnStartupSec= - od pierwszego uruchomienia serwera
  • OnUnitActiveSec= - od ostatniej aktywacji timera
  • OnUnitInactiveSec= - od ostatniej dezaktywacji timera
  • OnCalendar= - cykliczność - podobnie do usługi CRON
  • AccuracySec= - dopuszczalne opóźnienie aktywacji
  • Unit= - jeśli chcesz uruchomić usługę o innej nazwie

Specyfikacja czasu

(man systemd.time)

Poniższe informacje dotyczą całego systemd, czyli również journald.

Jednostki czasu:

  • usec, us
  • msec, ms
  • seconds, second, sec, s
  • minutes, minute, min, m
  • hours, hour, hr, h
  • days, day, d
  • weeks, week, w
  • months, month
  • years, year, y
Bez określenia (domyślnie) jednostki czasu: 50 znaczy 50 sekund.
Można łączyć, np: "2min 200ms".

Cykliczność: "minutely", "hourly", "daily", "monthly", "weekly", "yearly", "quarterly", "semiannually".

Znacznik czasu "timestamp" ma postać: "DayOfWeek YYYY-MM-DD HH:MM:SS": np:

Uwaga:

  • * = dowolna wartość
  • a/b = a, a+b, a+2*b, a+3*b,...

# "Podobnie" jak dla usługi CROND # skrót › rozwinięcie 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

Przykład 1: (każdego roku, 5 stycznia o północy)*-01-05 › *-01-05 00:00:00

Przykład 2: (każdego roku, 5 marca o północy i co dwa miesiące: 5 maja o północy, 5 lipca o północy,...)*-01/2-05 › *-01/2-05 00:00:00

Czas względny: # Załóżmy, że aktualny data to: 2012-11-23 18:15:22 +3h30min › Fri 2012-11-23 21:45:22 -5s › Fri 2012-11-23 18:15:17 11min ago › Fri 2012-11-23 18:04:22 11min left › Fri 2012-11-23 18:26:22 UTC: @1395716396 › Tue 2014-03-25 03:59:56

Podsumowanie

Przedstawiłem podstawowe zagadnienia związane z systemd oraz omówiłem krótko podstawowe typy unitów.
W następnych częściach: journald, nspawn, networkd, generatory...

Część następna 

linux porady

Komentarze

0 nowych
marcin1510   7 #1 30.10.2015 18:49

Nareszcie dowiedziałem się czym jest to osławione systemd. Z nim to jest taka sprawa, że w niektórych dystrybucjach z systemd wyłączona jest domyślnie usługa "NetworkManager", przez którą nie działa internet (wykrywanie modemu). Dotyczy to openSUSE, Fedory, Debiana.

etam   9 #2 30.10.2015 19:01

@marcin1510 Akurat w openSUSE to jest tak, że są do wyboru NetworkManager i wicked (zamiennik ifup). Podczas instalacji systemu, jeżeli nie ma obecnych kart bezprzewodowych, to domyślnie wybierany jest wicked. Na szczęście przełączenie między jednym a drugim to tylko kilka kliknięć w YaST.

marcin1510   7 #3 30.10.2015 19:21

@etam - o tym nie wiedziałem. Po prostu byłem przyzwyczajony do NetworkManagera. Wszędzie w internecie natykałem się na tę usługę - więc nie wiedziałem o istnieniu czegoś innego. Tak na prawdę gdyby nie to, że na kilku dystrybucjach trzeba tę usługę włączać, pewnie nie używałbym kubuntu i przeniósłbym się gdziekolwiek indziej.

awangardowy   7 #4 30.10.2015 19:27

b. dobry wpis, najlepszy jaki tutaj przeczytałem od miesiąca.


będzie coś o cron /crontab ?

  #5 30.10.2015 20:05

Ten wpis jest jak systemd ;)

wlprzemek   5 #6 30.10.2015 21:34

Dobry wpis, proszę o więcej tego typu...

pocolog   11 #7 30.10.2015 22:48

Po co?
edit.
ok przetłuczaczyłeś kilku osobom manual. @awangardowy: "będzie coś o cron /crontab ?" Poważnie?
edit2.
@awangardowy: nie chce mi się czytać wszystkiego o systemd bo kompletnie mnie to nie interesuje ale skoro to twoj konik to @mariushko nie pisze o tym tu?:"Timer jest odpowiedzialny za uruchomienie usługi w określonym czasie lub/i o określonym interwale"

Autor edytował komentarz.
parranoya   8 #8 31.10.2015 16:36

Popraw błąd ortograficzy w pkt. 11. device - pliki użądzeń (man systemd.device)"

parranoya   8 #9 31.10.2015 16:51

Jedna usługa o tak szerokim spektrum działania... Nieźle to zwiększa wektor ataku dla crackerów.
Czy ktoś może mnie oświecić po co to? Chyba nauczyłem się uniksów zbyt dawno temu. Wszędzie te "automaty" i jak coś się wysypie to szukaj wiatru w polu. Nie ma to jak *BSD. Musisz zrobić wszystko samemu i jak coś nie działa to przynajmniej wiesz gdzie szukać.
Porównując 1:1 starszego Debiana z tym najnowszym, jakie realne korzyści daje systemd? Kiedyś go nie było i też wszystko dobrze działało.

  #10 31.10.2015 17:43

BRAWO !!!!. Chcę więcej.

wojtex   9 #11 31.10.2015 19:17

Do czasu pojawienia się systemd, Linux różnił się od Windows prostotą i filozofią opartą na działaniu na plikach tekstowych. Wszystko było wręcz banalne - struktura katalogów, katalog /home/user/.*, katalog /etc, skrypty rc.d itd. Z systemd tak łatwo już nie jest. Zainstalowałem ostatnio OpenSuse Tumbleweed z KDE5. Na początku niby OK, ale jak Plasma się posypała to klasyczne rm -r ~/.kde nie wystarczyło.

Nie mówię, że systemd to samo zło, bo za słabo je znam, ale faktem jest, że np. Slackware i Arch to w tym momencie dwie zupełnie inne dystrybucje.

  #12 31.10.2015 20:43

@parranoya: spokojnie, osobiście nie wróżę systemd różowej przyszłości ...nie takie potworki były forsowane przykładowo HAL i po kilku latach kończyły na kiblu...systemd to kwestia czasu aż ktokolwiek łącznie z Poetteringiem przestanie ogarniać ten postępowy wynalazek i zacznie się sypać. Oczywiście wtedy zaczną to łatać, zaklejać, chwytać się brzytwy w końcu masa nakładu pracy i kasy poszła na to wielkopomne dzieło ale losu programowego bubla nie oszukasz, wcześniej czy później zdechnie i pozostanie tylko w naszych wspomnieniach..hahahahahahah

ziupo   6 #13 31.10.2015 22:34

Świetna ściągawka, planujesz pełny opis w równie dobrym stylu?

nintyfan   10 #14 01.11.2015 10:06

@parranoya: SystemD uruchamia oddzielny proces, jako normalny użytkownik dla sesji, a więc nie jest tak źle. Poza tym, to systemD jedynie zarządza usługami. SystemD nie wchłonął zbyt wielu usług, dodaje po prostu funkcjonalność. Posiada funkcjonalność podobną do Xinetd, ale raczej wykorzystuje tylko poll lub select, a Poll i select nie otwierają drogi do ataku. Jedynym zagrożeniem może być KDbus, którego systemD może wymagać w przyszłości.

nintyfan   10 #15 01.11.2015 10:31

@parranoya: Co do korzyści, to choćby cgroups. Wyobraź sobie, że dwukrotne wywołanie funkcji fork, a w pierwszym procesie potomnym powoduje, że nad powstałym po drugim wywołaniu fiork nie ma kontroli.l Cgroups rozwiązuje ten problem. Poza tym, to systemd nie wymaga żadnych skryptów startowych do przetwarzania zapytań. Wcześniej każdy skrypt startowy musiał implementować t?ę samą logikę, a więc przeniesienie tego na jednego demona przynosi korzyści(m.in mniej błędów). Zresztą, to do tej pory mieliśmy zależności usług w sposób opisany w LSB i chyba Redhatowy, a kod odpowiedzialny za obsługę zależności musiał być dosyć skomplikowany. Dodatkowo systemD upraszcza uruchamianie i zarządzanie daemonami. Do uruchomienia wykorzystywane są sockety, itd. SystemD wprowadza również automounter.

nintyfan   10 #16 01.11.2015 10:33

@wojtex: Nie chcę Cię tym obrazić, ale doucz się. SystemD nie ma za wiele wspólnego z konfiguracją KDE, a problem jest spowodowany tym, że katalog z konfiguracją jest pod inną ścieżką. KDE4 ma konfigurację chyba w ~/.kde4, a plasma5 gdzieś w ~/.config

nintyfan   10 #17 01.11.2015 10:35

@Anonim (niezalogowany): Wszystko wcześniej czy później przestanie istnieć(poza światem), choćby współczesne programy mogą zostać przepisane na nowe komputery, np. jeśli zostaną wykorzystywane prawdziwe sieci neuronowe, itd.

  #18 01.11.2015 17:19

@nintyfan: "Wszystko wcześniej czy później przestanie istnieć(poza światem),"

zaręczam Cię że w przypadku systemd stanie się to szybciej...daje powiedzmy aż przejdą 3cykle żywotu debiana czyli mniej więcej w porywach do dekady..

  #19 01.11.2015 17:24

@nintyfan: jest taka prosta i niepisana zasada która zawsze się sprawdza w każdym aspekcie życia a już w aspekcie informatycznym tym bardziej JAK COŚ JEST DO WSZYSTKIEGO TO JEST DO NICZEGO..

nintyfan   10 #20 01.11.2015 18:04

@Anonim (niezalogowany): Czy ja pisałem, że systemD jest do wszystkiego? Robi to, co powinien robić każdy init, czyli kontrolować daemony. SystemD wchłonął jedynie xinetd, a poza tym ma trochę kodu z udev. Nie wchłonął nic poza tym/

  #21 01.11.2015 20:09

@nintyfan: amigo przede wszystkim nie żaden SystemD tylko systemd..
To, że nie pisałeś że systemd jest do 'wszystkiego' wcale nie dowodzi, że tak nie jest. Polecam zapoznać się z tym initem (ja miałem takową przyjemność zanim go porzuciłem na dobre i robi on stertę niepotrzebnych rzeczy, które nie należą i nigdy nie powinny nigdy należeć do jego spektrum obowiązków. Do czego to będzie prowadzić w przyszłości raczej nie trudno się domyślić przede wszystkim duża awaryjność, podatność na wszelakie błędy programistyczne i obniżenie bezpieczeństwa systemów korzystających z niego..Pomijam fakt, że w tym wynalazku maczają łapska zarówno amerykańskie korporacje jak i agendy rządowe ...

wojtex   9 #22 01.11.2015 22:37

@nintyfan: luz, może i tak jest. Ale od kiedy pamiętam KDE miało swoją konfigurację w ~/.kde. Pozdro.

  #23 02.11.2015 00:52

@marcin1510: Nieprawda, w Debianie network manager nie jest wyłączony donyślnie.

P.S. niektóre dystrybucje, jak Debian pozwalają dalej korzystać ze starego init, wystarczy podać odpowiedni parametr przed bootowaniem i system wystartuje calkowicie "po staremu" a systemd będzie nieaktywny. Poza tym, w Debianie ciągle mozna uzywać starych skryptów w /etc/init.d i systemd będzie je uruchamiał

pavbaranov   6 #24 02.11.2015 09:05

@wojtex: Tak, ale nastąpiły zmiany w celu dostosowania Plasmy 5 do "standardów" (bodaj XDG). Mając obecnie Tumbleweed z Plasma 5 masz tam część oprogramowania zbudowanego na KDE4 oraz środowisko wraz z KF5 i część oprogramowania zbudowanego na nim. Pierwsze swoje ustawienia trzyma w ~/.kde|.kde4 (w zależności od dystrybucji), drugie w ~/.config. Nadto część ustawień jest jeszcze w /etc/xdg/. W obu przypadkach, także w ~/.local.
Kasując ~/.kde4 wykasowałeś jedynie ustawienia programów pochodzących jeszcze z KDE4. Nie polecam natomiast mechanicznego wykasowania ~/.config, albowiem w tym katalogu lądują również ustawienia innych programów, które nie pochodzą z Plasma 5. Jeśli obecnie posypie się Plasma, to należy wpierw zdiagnozować przyczynę, a dopiero potem kasować co popadnie (bo niekiedy i tak nic to nie da, a środowisko np. potrzebuje po prostu innych ustawień bądź odinstalowania wadliwego elementu /Plasma 5 jest chyba bardziej wrażliwa na wadliwe elementy środowiska od KDE4; często jej posypanie się jest związane z niewłaściwym zainstalowaniem albo nawet i prawidłowym, ale wadliwego plasmoidu, a nawet elementu wystroju tego środowiska).

nintyfan   10 #25 02.11.2015 12:24

@pavbaranov: W przypadku awarii, to zawsze na pierwszym miejscu warto skasować ~/.cache.

pavbaranov   6 #26 02.11.2015 12:36

@nintyfan: Jasne, ale wojteksowi chodziło o stary "pomysł" na przywracanie domyślnych ustawień KDE. W Plasma 5 tak się nie da (tzn. nie tu trzeba szukać ustawień). Samo skasowanie ~/.cache/ w tym przypadku też niewiele pomoże (choć zawsze warto wykonać), bowiem Plasma stosunkowo niewiele tu rzeczy trzyma.

marcin1510   7 #27 02.11.2015 23:04

@ZxcV5
A to chyba mieliśmy do czynienia z dwoma różnymi Debianami, bo u mnie po instalacji nie była ta usługa włączona.

mariushko   2 #28 16.11.2015 16:15

@parranoya: zrobione, dzięki.

#WireBoot   5 #29 23.12.2015 15:38

Poradnik genialny. Tylko konkrety bez opowiadań i to mi się podoba, o to chodzi! Wiadomo co jak użyć. Czas na przesiadke z init na systemd :)