Vlákno názorů k článku
systemd zapíná podporu DNSSEC
od Lol Phirae - Až vám přestane fungovat screen/tmux, tak si nezapomeňte...
-
Filip JirsákStříbrný podporovatelVy se na serveru přihlašujete a pak pod tím přihlášením spouštíte služby? Normální je, že se ty služby spouštějí (obvykle automaticky) ze správce služeb.
Ta funkce dělá jenom to, že když se uživatel přihlásí a spustí nějaké programy, po odhlášení se ty programy ukončí. Což je to, co člověk očekává.
-
Ondra Satai NekolaZlatý podporovatelAle vzdyt ti rekl naprosto presne, proc je tva namitka zavadejici
-
Ondra Satai NekolaZlatý podporovatel
Ja netvrdim nic o tom, zda je nebo neni to chovani 230-ky spravne. Ale tva namitka, kde do toho tahas servery je totaln mimo. Tech se tohle vybec netyka.
-
Filip JirsákStříbrný podporovatel
Nejste totálně mimo. Různými podobnými způsoby to dělá spousta lidí, proto jeden z důležitých požadavků na „nový init“ byl ten, aby služby běžely jako normální procesy a nebyl rozdíl v tom, jestli je spustíte na popředí nebo jako službu. Řešili to noví správci služeb dávno před systemd, a systemd to řeší také.
-
Filip JirsákStříbrný podporovatel
Ano, existují takoví lidé. A ne jeden. Když napíšu, že to očekávají všichni, nebudu daleko od pravdy. Takže to reprezentativní vzorek je.
Vy jste si totiž v zápalu boje nějak nestihl uvědomit, jak to dnes v nejrůznějších systémech funguje, a že i vy patříte mezi ty, kteří takové chování očekávají. Jak to funguje v DE – přihlásíte se, spustíte nějaké aplikace, a když se odhlašujete, všechny spuštěné aplikace (prohlížeč, IDE, hra, OpenOffice…) se ukončí. Když se přihlásíte přímo k terminálu nebo přes SSH, přesunete nějaký proce na pozadí a odhlásíte se – shell vás buď varuje a nedovolí odhlásit, nebo vás odhlásí a ukončí i aplikace na pozadí. Dokonce i ve Windows nebo v Macu se aplikace při odhlášení ukončí, takže to není žádný vynález Linuxu.
Akorát že v linuxu to nefunguje úplně systémově, když se odhlašujete z DE, to ukončí aplikace, které DE spravuje, ale některé aplikace mohou být mimo jeho kontrolu a zůstanou běžet. Navíc asi není úplně v pořádku, aby se to chovalo pokaždé jinak podle toho, zda se přihlásíte přes DE, z terminálu, přes SSH nebo jakkoli jinak.
-
Vdaka ludom ako Vy mavam pocit, ze keby systemd zacal od verzie 235 nekonfigurovatelne pri zadani zleho hesla formatovat disk, najdu sa ludia tvrdiaci ze je to tak dobre.
tom@silver $ ssh home
Last login: Mon May 23 18:02:52 2016 from silver
tom@home $ cat /dev/random >/dev/null &
[1] 1231
tom@home $ logout
Connection to home closed.
tom@silver $ ssh home
Last login: Mon May 23 18:03:05 2016 from 10.0.0.6
tom@home $ ps ax|grep cat
1231 ? S 0:00 cat /dev/random
1243 pts/6 S+ 0:00 grep --colour=auto cat
tom@home $Takto to funguje v skutocnosti a takto to fungovat ma. Akekolvek ine chovanie je bug, podla mna i docela nebezpecny bug a ja ani neviem, co sa tu snazime riesit.
-
Filip JirsákStříbrný podporovatel
Nějak se vám tam vloudilo přesměrování standardního výstupu.
filip$ cat /dev/random & [1] 20933 filip$ logout zsh: you have running jobs. filip$ logout zsh: warning: 1 jobs SIGHUPed
Bash se chová stejně, akorát to nevypisuje.
-
Lol Phirae (neregistrovaný)
Nějak se vám tam vloudilo přesměrování standardního výstupu.
To bude patrně proto, protože na každém normálním (non-Jirsák) systému to jinak začne vypisovat random garbage na obrazovku. Jen u Jirsáka ne, takže nám sem pak Jirsák může pastnout "příklad", který si právě vycucal z prdele a o kterém tvrdí, že "tak to funguje".
-
Santiago (neregistrovaný)
Jenze SIGHUP neni primarne ukonceni, to je informace o tom, ze doslo k odhlaseni (uzavreni ridiciho terminalu). Pokud by je chtel ukoncit, tak jim posle SIGTERM a neposlusnym posleze SIGKILL.
Pokud program s odhlasenim nepocita, tak dava smysl ho pri odhlaseni ukoncit. To zajisti defaultni obsluha SIGHUP. Pokud ale program nema byt ukoncen pri odhlaseni, tak proste nastavi ignorovani SIGHUP (at uz to udela vyvojar z programu syscallem, nebo uzivatel pres nohup), a pak zabit neni.
-
Karel (neregistrovaný)
Někdy se to hodí. Někteří uživatelé (vlastně vývojáři) byly prasata a na serveru jsme běžně nacházeli plno běžících procesů, co by tam být nemusely. Takže po kanceláři bývaly plakáty, že spuštění s & je fajn, ale ať si to po sobě na konci práce zkontrolují a zabijí, co nepotřebují, aby jelo. Ale rozhodně by to nemělo zabíjet vše, protože zcela běžně tam byly věci, které jet měly. Například proto, že je dostal k testování někdo jiný, například lidé z helpdesku. Ti pro změnu neměli práva si tam služby spustit. Představa, že kvůli každému testu nějaký admin konfiguruje tu službu do initu, aby ji to spustilo "správně", mi přijde ujetá. Tam musí být nějaké hrozné nedorozumění.
-
Filip JirsákStříbrný podporovatel
Zkuste si to bez systemd. Přihlásíte se jako root. Spustíte webserver, běží vám na popředí, vypisuje zprávy na konzolu. Odhlásit se nemůžete, můžete server buď zastavit sám, nebo ho přesunout na pozadí. Dobře, přesunete server na pozadí. Teď už se můžete odhlásit – ale shell vám hlásí, že máte spuštěný job na pozadí a neodhlásí vás. Když budete na odhlášení trvat, ukončí i ten job.
Proto když dnes chcete spustit webserver, nespouštíte ho přímo v prostředí přihlášeného uživatele, ale spouštíte ho jako službu.
Příště bych doporučil opačné pořadí. Nejprve si uvědomit, jak to funguje teď bez systemd, a teprve pak případně nadávat.
-
> Příště bych doporučil opačné pořadí. Nejprve si uvědomit, jak to funguje teď bez systemd, a teprve pak případně nadávat.
http://pastebin.com/0pCyL8LG , aby som to tu zbytocne neplnil code tagmi.
Vase tvrdenia sa nezhoduju ani s mojimi skusenostami, ani so skutocnostou ktoru prave pozorujem :)
-
Filip JirsákStříbrný podporovatel
Problém je v tom, že nevíte, jak se v unixu spouští proces. Takže sice pozorujete skutečnost, ale jinou, než o které píšete.
-
Santiago (neregistrovaný)
Az na to, ze valna vetsina demonu se defaultne sama demonizuje - tedy oprosti se od ridiciho terminalu pomoci forku a presmerovani stdin/stdout. Demonizovana sluzba neni vazana na ridici terminal, ale stale je spustena z kontextu prihlaseneho uzivatele (podedi z daneho prostredi prakticky veskere nastaveni).
Ackoliv pro vetsinu ucelu se hodi spoustet systemove sluzby z kontextu initu (a to je jedna z mala systemd zmen, ktera se mi libi a kterou bych ji videl i ve svem initu), obcas se hodi i ten druhy pripad - spoustet sluzbu z kontextu uzivatele.
-
Filip JirsákStříbrný podporovatel
Az na to, ze valna vetsina demonu se defaultne sama demonizuje - tedy oprosti se od ridiciho terminalu pomoci forku a presmerovani stdin/stdout. Demonizovana sluzba neni vazana na ridici terminal, ale stale je spustena z kontextu prihlaseneho uzivatele (podedi z daneho prostredi prakticky veskere nastaveni).
Což je podle mne asi nejhorší důsledek používání ekosystému založeného na SysVinitu.obcas se hodi i ten druhy pripad - spoustet sluzbu z kontextu uzivatele
Čemuž systemd nijak nebrání. -
Santiago (neregistrovaný)
> Což je podle mne asi nejhorší důsledek používání ekosystému založeného na SysVinitu.
Nejhorsim dusledkem myslis rucni demonizaci, nebo spousteni z kontextu uzivatele?
K prvnimu: Proc? Ma to nekolik pozitivnich dopadu - napr. existuje jasna a portabilni signalizace rozdilu mezi startem sluzby (pred ukoncenim primarniho proces) a behem sluzby (po ukonceni primarniho procesu).
To je uzitecne mimo jine i pro chybove hlasky - ty prvni je ucelne vypsat uzivateli na konzoli pri pokusu o spusteni sluzby, zatimco ty druhe patri do logu.
K druhemu: striktne vzato tohle neni problem initu jako takoveho, ale shellovskych skriptu, ktere na nej distribuce nabalily. Tradicni init spousti sluzby ze sveho kontextu podle /etc/inittab. Ale je pravda, ze tradicni init ma ruzna omezeni, ktere se zacly obchazet prave temi shellovymi skripty.
>> obcas se hodi i ten druhy pripad - spoustet sluzbu z kontextu uzivatele
> Čemuž systemd nijak nebrání.
Az na to, ze je zabije po odhlaseni uzivatele, ktery je spustil.
-
Filip JirsákStříbrný podporovatel
To, že si kde kdo udělal vlastní správce služeb, vypovídá něco o kvalitě těch dříve používaných systémových správců služeb. Oracle se bude nahazovat normálně, a dá se očekávat, že postupem času se ta konzole na systemd napojí, samotná služba (databáze nebo WebLogic) poběží pod systemd a konzole bude sloužit jenom k ovládání.
-
Filip JirsákStříbrný podporovatel
Nejhorším důsledkem myslím to, že se program sám demonizuje. Vztah mezi rodičovským a dceřiným procesem byl na unixu ten nejlepší způsob, jak dceřiný proces spravovat. Myslím, že o kvalitě správce služeb vypovídá to, že programy udělaly fork a ten proces, na který správce služeb dosáhl, ukončily – aby se dostaly z dosahu správce služeb.
Problém je v tom, že ta aplikace se pak chová jinak, když ji spustíte na popředí (třeba kvůli ladění nebo jako vývojář), a když běží „standardně“ jako démon. Ten rozdíl mezi konzolí a logem je podle mne další nevýhoda. Očekávám, že když tu aplikaci spustím z konzole, uvidím všechny informace na konzoli. A když jí spustím jako službu, chci tytéž informace přesměrované do logu.
Navíc ta hranic mezi startem služby a jejím během je ve skutečnosti dost mlhavá. Když spustím webový server s aplikacemi přistupujícími k databázi, kdy je služba nastartovaná? Když nastartovaly všechny aplikace a připojily se k databázi? Připojení k databázi se provádí i při běhu služby, bylo by divné chyby jednou hlásit na výstup a jednou do logu. Nakonec bychom asi došli k tomu, že webový server je nastartován v okamžiku, kdy začne naslouchat na potu 80 – jenže i to se může změnit za běhu. A klidně si je může naplánovat při startu systému nebo na jinou událost.
striktne vzato tohle neni problem initu jako takoveho, ale shellovskych skriptu, ktere na nej distribuce nabalily
Ano, proto jsem také psal o ekosystému založeném na SysVinit.Az na to, ze je zabije po odhlaseni uzivatele, ktery je spustil.
Nesmíte věřit všemu, co se napíše v diskusi. Za prvé to ukončí pouze procesy, které byly součástí uživatelské session, přičemž ta session je pro uživatele jedna – takže když se přihlásíte vícekrát, ukončí se až s posledním odhlášením. Za druhé, uživatel má možnost spouštět služby svým jménem i mimo svou session. -
Santiago (neregistrovaný)
> Nejhorším důsledkem myslím to, že se program sám demonizuje. Vztah mezi rodičovským a dceřiným procesem byl na unixu ten nejlepší způsob, jak dceřiný proces spravovat.
V prve rade, spravce sluzeb nema spravovat procesy, ale sluzby. Sluzba je abstraktni koncept, ktere nabizi urcite operace pro spravce sluzeb (start, stop, restart, reload, ...). Jak je vnitrne usporadana (jeden proces, vic procesu, zadny proces), to uz je jeji interni zalezitost.
Tedy klasicky objektovy pristup.
> Problém je v tom, že ta aplikace se pak chová jinak, když ji spustíte na popředí (třeba kvůli ladění nebo jako vývojář), a když běží „standardně“ jako démon. Ten rozdíl mezi konzolí a logem je podle mne další nevýhoda. Očekávám, že když tu aplikaci spustím z konzole, uvidím všechny informace na konzoli.
Jako letity vyvojar sitoveho demona je ma zkusenost takova, ze pro ladeni/testovani samozrejme spoustim sluzbu interaktivne, ale demonizovanou, nikoliv na popredi (to je otravne, nebot by to vyzadovalo dalsi terminal ci ssh access pro klientskou interakci s demonem. Debugovaci hlasky jsou daleko uzitecnejsi v logu nez na konzoli, nebot se daji snadno pozdeji filtrovat / prohledavat.
> Navíc ta hranic mezi startem služby a jejím během je ve skutečnosti dost mlhavá.
V nekterych pripadech ano, vetsinou ne. Zminovany priklad s webserverem narazi na to, ze webserver neni jedna sluzba, ale vlastne sluzba se spoustou nezavislych podsluzeb (a vlastne by vyzadovala regulerni spravu sluzeb pro sve podsluzby).
Nicmene z hlediska startu sluzby jde taky o to, aby sluzba uz byla schopna reagovat na ostatni pozadavky spravce sluzeb. Tedy aby tam nebyl race condition, kdy sluzbu pustim a vzapeti ukoncim a pozadavek na ukonceni je sluzbe poslan pred tim, nez sluzba dokoncila start a tak ho nebyla schopna sama zpracovat.
-
Filip JirsákStříbrný podporovatel
V paralelním světě j by to vtipné bylo. Ale nenechte se mást, jeho komentáře v drtivé většině případů nepopisují realitu tohoto světa.
