HA, ha, zha zha muhahaha.
A teď si k téhle kaši ještě přidejte netplan. Badum tssss.
Systemd mi prostě přijde logikou fungování jako windows. Prostě asi kvuli neschopným adminům začal vznikat systemd, který začal řešit věci nejlépe jak mohl a sám ví jak to má být správně..
Je mi z toho na blití, boj se systemd jsem vzdal - už ho prostě používám, ale pozapínaných mám jen minimum věcí, aby se mi kvůli němu co nejmíň věcí rozbíjelo.
Takové kombo jako: nové distro + systemd + systemd-resolved + hostnamectl + netplan = to je prostě kouzelná skříňka, která se ani náhodou nechová predikovatelně. Minimálně když se něco začne srát, tak v první řadě ztrácím čas zjišťováním, jestli nemá problém samotné systemd.
Příklad - stroj nemůže resolvit z nějakého důvodu:
- stará situace bez systemd (ok bez systemd-resolved) - zkontroluju /etc/resolv.conf jestli tam mám správně nameserver, zkontroluju jestli se dostanu ze stroje na dané nameservery, pokud ano pravděpodobně je problém mimo stroj a mám to jakože za jistotu.
- se systemd - twl přes co vlastně resolvim, neni systemd nějak jeblý - jo aha už vim přes co resolvim a dokonce se na ty stroje dostanu a můžu ručně resolvit, tak proč to kua neresolví. Vystoupit/nastoupit a stále prostě nemám jistotu kde je zakopaný pes.
Se systemd prostě koexistuju, ale už z těch systemů nemám takový dobrý pocit, že je mám plně pod kontrolou a vím co dělají. Každým updatem systemd se děsím toho, co zas Poetering pohltil do systemd. Počítám, že budou následovat věci ohledně disků :-)
U systemd rozhodne neni nutne pouzivat vsechny jeho komponenty - a ne vsechny jeho komponenty jsou spatne. Vykopavat ale systemd jako takovy je nesmysl, ono to ma i sve pozitivni dopady (vedle par tech negativnich) a popravde jsem rad, ze je nejaka snaha to sjednotit i napric distribucemi... nektere veci jsou jinak, delaji se jinak - ale da se zvyknout a ve finale to az tak strasne neni, bavime-li se ciste o initu...
Tak treba pricetne vyresene zavislosti sluzeb (v configu, tedy lip, nez psanim jakychsi hlavicek do vykonnych shell scriptu) vcetne pokrocilych moznosti jejich izolace, monitorovani jejich behu a treba i automaticke restartovani v pripade jejich padu bez nutnosti to bastlit nejak jinak (ano, znam treba monit), paralelizace a tedy zrychleni startu (ktery zpomalovalo i parsovani/interpretace dlouhych startovacich shell scriptu)... Ono se toho najde dost. Chapu, ze na nejakou domaci Raspberry, kde si clovek hlida dva GPIO piny je to kanon na vrabce, ale na serveru to smysl rozhodne dava...
Jakze? Zavislosti sluzeb ma gentoo v openrc kolik ... 10+ let? A narozdil od ty sracky to funguje. Monitorovat to NIC neumi, jen to blaboli neco o tom ze neco je v ramce, ale nema to ani paru jestli to bezi, naopak, srackomet systemd si dovoli slubu ve skutecnosti nenastartovat, a jen se tvari ze bezi. A automatickej reset? To muze myslet vazne leda totalni imbecil ... kdyz neco padne, tak to ma duvod. O paralleni start nikdo nestoji, v zadnym pripade. Nezrychluje to vubec nic, jen to zpusobuje prusery (a openrc to umi taky, ale je to zcela pricetne bydefault vypnuty).
Takze se nenajde absolutne vubec nic, jen blabolis.
Ja jedu na NTB Debian 9 s Mate a without-systemd. Uplne v pohode. S chuti tedy do toho a nejen na serverech.
Ano .. to sice ano, ale ostatni veci funguji stejne jako pred tim. Bohuzel praseni sitovych rozhrani se metodou without-systemd resit neda. Coz jsem ostatne nikde netvrdil ze mam zpet i eth0 eth1 atd. A rad bych mel a pochopitelne na to casem prijde take rada nalezt jednoduche reseni jak se dostat zpet do puvodniho stavu.
Tak diky pane Caletka za nakop, cas prisel drive nez jsem cekal.. :) Uz mam zase vse tak jak drive. Pouzil jsem metodu s parametrem pro boot jadra zadavany do grubu, update-grub a reboot. Dokonce jako vedlejsi efekt jsem odhalil, ze na mistni siti nejaky lajdak pustil druhy DHCP server distribuujici konfiguraci s neexistujici GW, coz zpusobovalo zridka kdy nahodne necekane liznuti si spatne konfigurace z druheho DHCP, ale to je spise jen proto, ze jsem se vrtal podrobneji v sitovem nastaveni a tuhle zhovadilost objevil. Takze dve mouchy jednou ranou. Díky a jeste jednou diky :)
root@ntb:/# ifconfig -s
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 428 0 0 0 487 0 0 0 BMU
lo 65536 7423 0 0 0 7423 0 0 0 LRU
wlan0 1500 37800 0 0 0 27162 0 0 0 BMRU
root@ntb:/# cat /etc/*elease
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@ntb:/# ps ax q 1
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 init [2]
V maji som upgradol z wheezy na stretch (jessie so preskocil, respektive to bol len nutny medzikrok v upgrade).
Na serveroch mam sysvinit-core + sysv-rc (teda boot po starom, uplne bez problemov).
Na desktop som dal sysvinit-core + openrc (na niektore demony som spravil vlastny openrc-konfigurak namiesto initskriptu), plus niektore baliky som nahradil tymi z https://angband.pl/deb/archive.html (veci ako policykit, udisks2, kvoli tomu aby KDE nebolo ozobracene o niektore funkcie). V sddm nefungovalo vypinanie a reboot (odmietli podporovat consolekit a pouzivaju len libpam-systemd), takze namiesto neho pouzivam lightdm.
Systemd je zablokovany cez apt-pinning (okrem balika libsystemd0), aby sa mi tam zakerne nenatlacil pri instalacii nejakeho uplne ineho balika. V pohode to pouzivam bez systemd (ten sddm je jedina vec na ktoru som narazil, ze bez systemd nefunguje, a to mi nechyba).
Na desktop som zvazoval Devuan, ale odradilo ma, ze su s vydanim pozadu aj za stable Debian-om, plus maju o dost slabsiu dokumentaciu balikov na webe.