Vlákno názorů k článku Nebojte se systemd: cíle od j - "kupříkladu při vypalování CD nechceme vypnout počítač" ... parada,...
-
j (neregistrovaný)
"kupříkladu při vypalování CD nechceme vypnout počítač"
... parada, dalsi windowsovateni tuxe ... widle se taky nevypnou, kdyz si usmyslej, ze se vypnout nemaj. Takze tu mame novou ubervlastnost tuxe - nejde to vypnout, treba proto, ze vytuh vypalovaci soft ... uzasny.
Pro widle existuje hromada appek, ktery se odmitaji vypnout i s force shutdown. Takze hura, budem ke vsem tuxum pripojovat HW resetatory, aby to s timhle smejdem resetnou slo.
-
> Presne preto je tam ten parameter "-i" ktorym vies ignorovat inhibitory.
Kdyz uz je tu odbornik, potreboval bych vedet, jednu vec: vyhodili proud a po mesici se mi rebootovalo Jessie. Boot trval pres 5 minut, fsck jsem tam nevidel, jen nejaka odpocitavani s napisy jako [30/unlimited]. Kam muzu dat ten parametr -i?
Jo, jen pro poradek, o vikendu dhcpd prevzal vladu nad raspberry pi a musel jsem ho vypnout, abych mohl mit statickou adresu. ( systemctl disable dhcpd , kdyby nekdo potreboval)
-
dustin (neregistrovaný)
Jo, unlimited timeouty, to je vychytávka http://www.root.cz/clanky/nebojte-se-systemd-jednotky/nazory/876735/ . Mrkni na ten http://unix.stackexchange.com/questions/186162/how-to-change-timeout-in-systemctl/264286#264286 a zkus si dokonfigurovat timeout na příslušné unit.
-
Sten (neregistrovaný)
Ano, unlimited timeouty jsou špatné. Stejně tak jsou špatné limited timeouty. Pro odpůrce systemd je zřejmě špatné úplně všechno, s jedinou výjimkou, a tím jsou unlimited timeouty sysvinitu, protože žádné nemá a systemd tam žádné nenarvalo; a až to udělá, to zase určitě bude řevu.
-
nobody (neregistrovaný)
@Sten
ale jisteze sYsTeMd logo ma a je vystizne, znazornuje spokojenost uzivatelu a radosti ktere prinasi... -
Zdar. Nevim tak uplne jiste co je spatne a co je dobre, jestli jsem odpurce nbo priznivec. Jen je mi divny, ze debian, kteryho jsem si vybral pro extremni predvidatelnost mi po upgradu do Jessie a pozdejsim vypadku proudu nenabehl, protoze mu najednou vadilo neco v fstab a ted zase ma takovyhle cekani, ktery driv nemival.
Nestezuju si, jen mi prijde, ze by mi to melo po upgradu fungovat lepe nez driv. Jinac bych neupgradoval. Jestli za to muze nejaky system de me vlastne nezajima. -
Sten (neregistrovaný)
To záleží, co konkrétně to odpočítávalo. -i vypíná inhibitory, které brání přejít do jiného cíle, takže se tohoto případu (spouštění služeb) vůbec netýkají. Jestli to opravdu bylo dhcpd, pak tam máte nějak zprasené nastavení, protože spuštění sítě má limit 90 sekund.
-
j (neregistrovaný)
Jo, widle na to maj -f ... a funguje to rek bych uplne stejne. Tedy nahovno ...
On totiz normalni admin ocekava, ze kdyz da shutdown, tak se proste provede, a ne ze to na nej bude mit kecy, ze nejde to ci ono ukoncit. Kdyz reknu ze chci zasrelit kernel, tak to system ma bez kecu udelat.
Nehlede na to, ze ja tu uz bylo parkrat zmineno, sytemda sracka promptne sejme sshd ... takze kdyz to na necem podobnym zustane viset, znamena to udelat si vejlet na misto ... uzasny.
-
čumil (neregistrovaný)
A když je server pár tisíc kilometrů daleko + je o půlnoci, tak server prostě nepoběží :D teda, ještě že nejsem nějak vázanej na linux, asi bych na toho idiota lennarta chtěl někoho poslat.
Zatím je mi to jedno, pokud se ale linux zwokní tak moc až to bude problém používat, nahradím ho BSD ...
-
Sten (neregistrovaný)
Nestěžoval sis náhodou u předchozího článku, co si to systemd dovoluje, že sestřelí služby, které se nechtějí ukončovat? Tak si laskavě napřed rozmysli, co vlastně chceš. Protože nemůžeš mít zaručené ukončení a zároveň žádné timeouty.
systemd dělá vše v transakcích. Pokud inhibitor blokuje přechod do nějakého cíle, tak se vůbec nezačne. Pokud ale přidáš -i, tak se to provede a na ničem to viset nezůstane.
-
Sten (neregistrovaný)
Jak jsem už odpovídal v předchozí diskuzi, tak to jsou jen kecy. Jak těch 30 let, protože sysvinit v Linuxu je jiný, než býval v UNIXech (zkus si najít, co znamená LSB init), a v opravdových UNIXech už pěkně dlouho není, protože ho nahradily služby jako launchd či SMF. Dále sshd se ukončuje dřív než většina ostatních služeb i se sysvinitem (výchozí priorita K02, třeba databáze mají K03 a libvirt K05), takže klidně si tu snaž tvrdit, že pokud se to zaseklo, tak jsi to opravil SSHčkem, ale nic víc než lež to není. Chybějící timeouty má systemd pouze pro init.d skripty, které mimochodem spokojeně vytuhávaly i se sysvinitem (třeba pokud vypadlo spojení pro NFS), protože tam timeouty nikdy nebyly a systemd je tam nedalo, protože by to bylo špatně. Ale že tam nejsou, je evidentně taky špatně.
-
Sten (neregistrovaný)
Nevím, jaký Linux máš, ale bude to nějaký supertajný j Linux. Žádnou distribuci Linuxu bez systemd, kde by se sshd spouštělo hned po spuštění sítě, neznám. Možná to bude i tím, že sysvinit nic takového jako start po spuštění sítě neumí.
Nestalo? To máš teda evidentně hodně velké zkušenosti s administrací serverů :-D
-
S tím ssh je to trochu jinak.
Spojení na ssh se neukončí po ukončení služby sshd. Takže po ssh můžete klidně sshd konfigurovat, vypnout, zapnout a aktuální připojení dále funguje.
Z tohoto pohledu je jedno, kdy se při vypínání OS ukončí služba sshd. (Jen po jejím ukončení už nové spojení nenavážete.)
Problém je ve chvíli, kdy systemd začne střílet session při vypínání os. Ty střílí dost brzo, takže ssh spojení se ukončí prakticky hned. Bylo by dobré, kdyby ssh spojení ukončoval až těsně před odpojením sítě.
Btw, zkoušel někdo ty další způsoby ssh v systemd:
ssh.service ssh@.service ssh.socket? Nebo zůstáváte klasicky u ssh.service? -
j (neregistrovaný)
S tim ssh se to ma tak, ze pokud mu reknu, ze ma byt posledni co se vypina pres ukoncenim site, tak proste bude, a do ty doby se na to i zvenku pripojis. Samo, na svepravnym systemu. Se systemd se na to nepripojis ani po bootu, pokud si ta zhuverilost usmysli, ze to neni ten servis kterej by byl treba.
Stejne jako na normalnim systemu nejdriv nastartuje firewall, a teprve pak zacnou startovat sitovy sluzby ... se systemd ti bezej sitovy sluzby ... a firewall (mozna) nastartuje nekdy casem ...
-
Sten (neregistrovaný)
Že tě ty pohádky o zlém systemd baví…
Pokud to tomu initu řekneš… A teď si představ, že pokud to řekneš systemd, chová se to naprosto stejně. Překvápko, co?
systemd kupodivu nespustí službu, pokud nemá zadáno, že ji má spustit. Možná tě to překvapí, ale tak to funguje v Unixech už … no vždy, že každý normální systém spouští jen to, co má nastaveno, že má spouštět. Pochlub se, kterou náhradu initu používající křišťálovou kouli používáš? sysvinit, upstart ani OpenRC totiž nespouští služby, u kterých nemají nastaveno, že se mají spustit.
Každý normální firewall v systemd má
Before=network.target, takže se nespustí až po spuštění síťových služeb. -
Ta uspora zdroju tim ze nebezi sshd trvale je zanedbatelna. Takze zustavam u klasiky.
Me by zase celkem zajimalo, jestli nekdo zkousel dat ssh demona do emergency targetu. To je neco co se tezko udela s klasickym initem, ale systemd se mi na to zda jak delane.
Proste aby server, ktery nedokaze normalne najet byl i tak vzdalene pristupny pres nejaky Dropbear a schopen opravy.
-
nobody (neregistrovaný)
proc by to slo tezko? nesouvisi to ani tak s initem, jako s initramfs, proste si tam das dropbear a pridas jeho pousteni v pocatku init scriptu v initramfs a ukoncis ho az z rootfs system nabehne...
napr pred 10lety dropbear v initramfs pro vzdalene odemnuti luks disku s rootfs...
http://gpl.coulmann.de/ssh_luks_unlock.html -
@Sten:
Dále sshd se ukončuje dřív než většina ostatních služeb i se sysvinitem (výchozí priorita K02, třeba databáze mají K03 a libvirt K05), takže klidně si tu snaž tvrdit, že pokud se to zaseklo, tak jsi to opravil SSHčkem, ale nic víc než lež to není.
Zajimave. Tak jsem ted zkusil tohle:
root@a10Lime:/etc# ls -lR /etc/rc* |grep ssh
lrwxrwxrwx 1 root root 13 Jun 11 20:00 S02ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 Jun 11 20:00 S02ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 Jun 11 20:00 S02ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 Jun 11 20:00 S02ssh -> ../init.d/sshA furt tam nevidim to k02 pro sshd. Ono to tedy nejspis bezi, dokud se neukonci sluzby pomoci init skriptu a pak teprve tomu jadro posle sigterm a kdyby to zustalo viset, posle se tomu sigkill. Ale at je to, jak je to, jakmile spustim reboot, tak se to se mnou nebavi.
