Systemd změnil výchozí hodnotu v souboru logind.conf na „yes“, což znamená, že budou zabity všechny procesy uživatele, který se odhlásí. V Debian bug trackeru už je nahlášená chyba.
Nová změna totiž značí, že uživatelské procesy budou po odhlášení zcela vyčištěny, včetně těch, které ale potřebuje uživatel nechat běžet na pozadí. Aby tyto procesy přežily, je nutné uživateli aktivovat „lingering“.
A to este asi nie je vsetko. Podla toho, co som cital v changelogu, tak bude killovat aj procesy at a cron, resp. pre neprihlaseneho uzivatela ich ani nebude spustat. Samozrejme vsetko sa to da nastavit volbami, ale toto je vychodzie nastavenie. Asi bude viac pouzivatelov nespokojnych.
Ono je to vselijaky. Napr. predchozi verze system-d zacalu uzivatelum mazat shared-memory segmenty. Coz zpusobovalo pady databazi. To se driv na Unixu nikdy nedelo. Tak se ale ukazalo, ze nekde v systemd je harcodovana konstanta 1000. A k uzivatelum s uid < 1000 ("systemovym") se to chova jinak nez k tem ostatnim. Tech zmen oproti normalu je tolik, a prichazeji plizive bez varovani, tohle se zadny jiny vendor (ani MS) ke svym zakaznikum nedovoli.
Tady je ten commit.
https://github.com/keszybz/systemd/commit/33a0b1461db30056d43b712f65aedfcddc07b0c6
Pry to resi nejaky tenhle proble s d-busem
Jo, edit: Tohle je oblzvast uzasny v tom, ze padne linka, staci na chvilku, a dzob se proste sestreli ... lol. Takze bezi trebas aktualizace nejakyho softu, kera muze bezet par hodin, a kdyz se zhrouti, rozjebe to uplne vse ... a systemd zvedne pravdepodobnost takovyho stavu na 100% ...
Tak oni to sice rozbijeji postupne, ale to jim prece nebrani v tom, aby veci rozbili opakovane, dokonce pokazde jinym zpusobem. Oni asi maji v kanclu michacku na beton, v ni papirky se jmeny veci, ktere je potreba rozbit. A vzdy, kdyz delaji novou verzi, michacku zapnou, pak do ni Poettering hrabne a vytahne nahodne velkou hromadu papirku a hned vedi, co je treba zkurvit.
Jo, presne wo to tady go: je zapotrebi neco rozes*at (nejlepe to co dlouho funguje), pak si lidi budou stezovat, az prijde velkej mesias Poettering a zahrne to primo do systemd.
Budoucnost je jasna, a odpor je zbytecnej. A rok 2020 bude prvni, kde na poli operacnich systemu systemd porazi windows...
Ten uz davno predcili. V celem Linuxu se kazdy den najde tolik bugu, az to hezke neni. A nez nekdo zacne placat neco o open source a jak pomaha (pomaha, ale ne v pripade Linuxu ;D) eliminovat chyby, tak by se mel zamyslet a uvedomit si, ze pokud se neco zlepsuje, tak ma chyb ubyvat a ne pribyvat :D
kolik chyb se NEnajde ve Windows, resp. kdyz je najdou v Microsoftu, jak dlouho je nechaji vyhnivat protoze o tom nikdo nevi (nebo si to alespon mysli)...
kdyz budes chodit srat do parku, tak muze te kazdy sledovat a delat rozbor co si mel k obedu pripade te objednat k lekari kdyz zjisti problemy, pokud ale seres doma na zachode, tak nikdo nic nezjisti a ty sam to hlasit do sveta nebudes... a s Microsoftem to mas to same, sere si jen doma... ale narozdil od tebe nasira vsechny okolo ktere s nim maji neco spolecneho :)
https://github.com/tmux/tmux/issues/428
Vyvojar systemd pozaduje po vyvojarich tmuxu, aby pridali kod pro podporu systemd...
A navrhuje k tomu pouzit dbus :-D
Se divte ... onehda sem rval na jednoho podobnyho idiota, kdyz sem u zakose patchul ssytem, a vsechno prestalo fungovat ... protoze oni se rozhodli, ze misto param=hodnota se bude ponovu pouzivat hodnota=param. Prej aby to bylo konzistentni se zbytkem aplikace. Ze na to zakaznici maji napojeny dalsi svoje veci (za miliony) jim vubec nedoslo ... nakonec sem je dokopal (skoro doslova) k tomu, ze deklarovali jeste verzi, a kdyz nebyla, tak se to chovalo postaru.
A vyvojari tmux, kteri jsou v OpenBSD mu reknou svoje a poslou ho nekde :D Jednak uz ted je Gnome vzdy v OpenBSD drive nez v Linuxu, diky www.mtier.org , www.esdenera.com a dalsim (DuckDuckGo, Google, Facebook, Microsoft, Ebay atd. kteri davaji vice a vice penez do xBSD) a druhak maji davno sve BSD wrappery pro ty systemd srance.
Ono teoreticka sance tu je, ze by kod pro podporu systemd se mohl objevit v OpenBSD. Ma to par jednoduchych podminek.
1) Kod musi splnovat naroky na bezpecnost z OpenBSD, ne tu parodii z Linuxu
2) Kod musi byt kvalitni, prehledny a dokumentovany a ne to co je v systemd a jinde v Linuxu co vypada jak kdyz to prase pise certovym kopytem :D
3) Musi to vyvojar poradne zdokumentovat a man stranka podle toho musi vypadat a taky to musi jit pres mandoc. Jak vidim co vypousti RedHat a ty kecy o tom, ze kdyz chce nekdo dokumentaci, tak at si precte zdrojak, tak se nebojim toho, ze by v brzke dobe neco ze systemd bylo v Linuxu
4) Domrvit screen jeste vice nez je si na Linuxu porad muzete a zkusit ziskat pozici tmux :D
Jo, tak nějak poslali, zato maintainer z Debianu tam chtěl ochotně přidat závislost tmux-u na systemd. Ta distribuce je ztracená, nejvyšší čas opustit potápějící se loď.
Co bys ty tatareh chtel resit? Ychtylovy podobnymu tobe negunguje rozjebany gnome, a proto chce po systemd aby to sestrelovalo ... a kvuli tomu maj vsichni predelavat vsechno, co funguje 30let? Proc by meli, oni nic rozbityho nemaj. A pridavat dalsi zavislosti == dalsi bugy.
Presne jako ve widlich. Misto textaku v XP do kteryho staci pripsat radek a je dalsi polozka v bootu ... mame od vist peknou binarku ... ke ktery M$ nejak opomel dodat tu GUI appku (dyk prece ve widlich se da vsechno delat z GUI ...) a tak kdyz nekdo chce zmenit boot, potrebuje si na to sosnout nejakej externi, dost pravdepodobne zavirovanej tool. Bomba.
I kdyby tam totiz tu zavislost pridali a rozbili tak vlastni SW, tak to stejne fungovat nebude, protoze ti kreteni za tyden zmenej rozhrani.
Na tej issue inac je krasne demonstrovane ako banda anti-systemd riesi" problem. Miesto technickych veci spamovanie threadu
Problém je vyřešen zde. Tečka. Konec technické diskuse. LP a jeho banda análních řiťolezců žádný problém nevyřešila, naopak spoustu věcí rozbila a jako vrchol má tu drzost chtít tu svojí sračku nacpat do dalších projektů, kde vůbec není potřebná.
Komentoval jsem "žádost" jakéhosi Poetteringova poskoka, aby vývojáři tmuxu nacpali do jejich projektu kód závisející na DBUSu, potažmo systemd. To je totiž přesně ten styl celé té grupy mlamojů okolo LP - oni rozbijou léta fungující věc, a pak chtějí po jiných, aby následky opravovali. Tenhle jejich modus operandi je neměnný již léta. jak si všimnul mj. Linus T..
Co je na té žádosti špatného? Stejně jako ty píšeš žádosti, aby ostatní nepoužívali systemd, vývojáři Red Hatu a Debianu píší žádosti o podporu nových vlastností.
Všiml jsem si tam ale jednoho zásadního rozdílu oproti tvým žádostem. Nikdo tam nenadává vývojářům, že jsou blbci, ale snaží se přijít na nějaké rozumné řešení. Jak tam psal kentfrederic, POSIX tohle vůbec neřeší (a systemd rozhodně není jediný, kdo zabíjí procesy při odhlášení, MacOS X to dělá taky), takže nezabývá než vymyslet nějaké vlastní řešení. A dobrali se toho, že by to tmux měl dělat přes PAM, protože to neřeší jen problém se systemd, ale i problémy s SSH a GPG agenty. S čímž vývojáři systemd neměli problém, nikoho nenutí, aby to muselo být jedním konkrétním způsobem.
Co je na té žádosti špatného?
To je vážně míněný dotaz? Kterou část z toho, že nový dbus rozbil Gnome -> jeho poskok si šel postěžovat -> LP vymyslel "řešení", že bude při odhlášení defaultně vraždit všechny procesy a přitom rozbil desítky let zcela bez problémů fungující věci (tmux/screen, mj.), potřebuješ ještě dovysvětlit? Takže výsledek je ten, že mlamojové kolem systemd rozbili hned několik věcí, vopravili velký hovno a ještě maj tu drzost "žádat" oběti jejich sabotážní činnosti, ať se s tím smíří a zařídí se podle toho? To je neuvěřitelný chování, tohle.
Změnit fungování a rozbít jsou dvě rozdílné věci, což ovšem církev LP již léta odmítá chápat. Oni to navíc rozbíjejí úmyslně a zcela nesmyslně. A vyžadují po ostatních, aby následky jejich neumětelské činnosti neustále napravovali. A v rámci téhle sabotážní činnosti jako infekční chorobu šíří po nejrůznějších projektech závislost na té jejich sračce.
Tož asi tak. Další debata zjevně nebude produktivní.
Změnou fungování se téměř vždy něco rozbije. V tomhle případě jde o nestandardní chování Linuxu při odhlášení, které třeba na certifikovaném UNIXu MacOS X (či kdysi certifikovaných Windows) není (a kde tmux taky nepřežije). Navíc problémy s tím nemá jen systemd, ale i SSH a GPG agenti, pam_ecryptfs a nejspíš mnoho dalšího software, který závisí na sezeních. Že to dosud nikdo neřešil, neznamená, že by bylo špatné to chtít konečně vyřešit, pouze že to dosud nikoho nepálilo tolik, aby tomu věnoval úsilí. Autoři tmuxu mají nakonec taky názor, že by to tmux měl řešit, jen se liší tím, jak by se to mělo udělat (nepřímo přes PAM místo přímo v systemd).
Ano, debata s tebou zjevně nemůže být produktivní. Poettering ve tvých představách zřejmě nutí správce ostatních distribucí přecházet na systemd unášeních jejich dětí a stejně tak autory dalších projektů nutí začleňovat podporu systemd umisťováním bomb pod sedadla jejich aut (pominu teď to, že je v té „sabotážní činnosti“ velmi nedůkladný, když mu stačí podpora PAM, který funguje i se sysvinitem a upstartem). Nedovedu si totiž představit, jakým jiným způsobem lze ve světě open source software někoho nutit něco implementovat. Dobrá zpráva pro tebe je, že taková paranoia se dá celkem dobře léčit, když se stavíš na adrese Ústavní 7, Praha 8. Anebo můžeš místo pomlouvání lidí, kteří něco dělají, také začít něco dělat a přidat se do vývoje Devuanu. Konkurence odjakživa žene vývoj kupředu.
Problem je v tom, ze neexistuje moznost, jak otestovat takovehle zmeny proti kazdemu SW, zvlast v tak rozsahlem svete utilit a buhviceho. A cekat na vsechny, az to opravi, tak to by se taky nemuselo vubec dockat. Navic, musi byt vuci cemu testovat opravy. Tohle je zacarovany kruh, ktery se bez rozbiti neceho neda vyresit.
====
A cekat na vsechny, az to opravi, tak to by se taky nemuselo vubec dockat.
====
A nebo tu změnu vůbec nebudu dělat. Např. nevidím důvod, proč by mi po odhlášení měl systém shodit všechny procesy, které jsem si při přihlášení nastartoval. Každá učebnice linuxu popisuje, jak spustit proces tak, aby přežil zavření terminálu/odhlášení (nohup, přesměrování in/out atd.). Přestanu tohle např. na debianu stable po upgradu platit?
Zatím je to v Debianu vypnuté, dokud se tohle nevyřeší. screen a tmux by měly používat PAM sessiony, čímž tohle (a další podobné problémy) vyřeší. U nohup zatím není rozhodnuto, ale třeba v MacOS X také nefunguje. To, že se k němu nedá opětovně připojit či taková sezení vůbec vypsat, se tam bere jako zásadní nedostatek, kvůli kterému stálo za to jej zabít. Podobně byl na Linuxu používán a následně zabit třeba finger (schválně kolík systemd-haterů vůbec tuší, k čemu sloužil) a dnes po něm už nikdo ani neštěkne, protože všichni jsou zvyklí na PAM.
Tak užitečnost fingeru a nohupu je asi trošku jiná, ne?
K nohupu se nepotřebuju připojovat. Prostě stačí, že ten proces běží dál. Potřebuju-li se připojovat, vyřeším si to screenou/tmuxem.
Kolik na debianích strojích běží legacy skriptů používajících nohup? Ty najednou přestanou fungovat? K čemu je taková změna dobrá?
finger se dřív používal pro zjišťování informací o uživatelích. Taky na tom záviselo spousta skriptů a aplikací, obzvlášť v sítích s centrální správou uživatelů. Dneska už ani není součást standardní instalace, protože byl plně nahrazen getent. (Omlouvám se za trochu zmatení. Za tu změnu nemůže PAM, ale NSS.)
> Problem je v tom, ze neexistuje moznost, jak otestovat takovehle zmeny proti kazdemu SW, zvlast v tak rozsahlem svete utilit a buhviceho.
Ale no tak. Ak tomu typkovy nebolo *okamzite* jasne, ze takato zmena rozbije stovky cudzich rieseni, nemali by ho pustat ku klavesnici. A radsej ani k ostrim predmetom.
Skutocnost je ale taka, ze jemu to jasne bolo a nic testovat nepotreboval. Proste usudil, ze sa svet prisposobi jemu.
No to je zas radost číst... :(
Já prostě nedokážu pochopit, jaktože někdo, kdo píše zcela klíčovou komponentu OS (druhou hned po kernelu) a je za to placený mezinárodní korporací může takovýhle věci řešit až jako bugreporty. To jako lidem kolem systemd nedošlo, že asi lidi budou chtít používat tmux?! Proč neexistuje předem tabulka "tyhle typy sessions budou, mají tyhle a tyhle záludnosti a budeme je řešit takhle a takhle"? Fakt mi to hlava nebere, jak můžou lidi z RedHatu pracovat tak, že úplně libovolně cokoli rozbijí a až se někdo ozve, tak hledají řešení.
jsem v it pres 20 let, zacinal jsem s unixware, pak linux a vse ostatni (*bsd, irix, aix, solaris, windows)
Co mne posledni dobou sere, je, kdyz si nekdo instaluje desktop a pak chce pomoct. Ikdyz jsem vzdy preferoval Debian, dneska musim:
- dat pryc avahi, to psalo totalni prase. dat do kodu domenu "local", to je na kulku
- dat do hajzlu network manager, protoze pak je zacatecnik porad pod " utokem" nesmyslnych chyb/vlastnosti
Na serveru je to zas zpotvorena debilita systemd, plus na debianu ta binarka, pres kterou systemd spousti scripty, aby nezapisovaly pri paralelnim startu asynchronne na konzolu. Idiot uchylna to tam dal.
Pochopim paskvil jmenem selinux, NSA vi, co dela. Ale proc tyhle Potteringovy halucinogenni polutivni kreace konci ve "stable", nad tim zustava rozum stat
dat pryc avahi, to psalo totalni prase. dat do kodu domenu "local", to je na kulku
.local zavedlo RFC 6762. Avahi je pouze implementace toho standardu. Jestli používáte neregistrované domény, porušujete několik jiných RFC a je váš problém, že to novější RFC rozbily.
dat do hajzlu network manager, protoze pak je zacatecnik porad pod " utokem" nesmyslnych chyb/vlastnosti
To záleží, jak divnou máte síť (vzhledem k předchozímu bych řekl, že hodně). S NetworkManagerem jsem už několik let neměl problém. Dokonce umí takové věci jako restartovat VPN při změně spojení.
na debianu ta binarka, pres kterou systemd spousti scripty, aby nezapisovaly pri paralelnim startu asynchronne na konzolu. Idiot uchylna to tam dal.
Ono totiž když píše několik procesů přes sebe, tak se to skvěle luští… Tohle dělá i sysvinit, pokud ho přepnete na paralelní spouštění.
Pochopim paskvil jmenem selinux, NSA vi, co dela.
Co je na SELinux za paskvil? Tedy pokud neplatí, že paskvil == to, co neumím používat a jsem příliš líný si o tom něco zjistit. (Mimochodem SELinux je v Debianu ve výchozím stavu vypnutý.)
O skvělém vynálezu .local chvíli vyprávějte třeba adminům velkých AD domén. Ale nevím, jaký budete mít úspěch. Raději si před tím oblečte ochranné pomůcky pro hokejisty.
SELinux není strašný z principu toho co dělá. Je dokonce velmi užitečný. Jeho rozhraní pro administrátora a ten "overengineering" jsou ovšem tak strašné, že to spoustu lidí donutí jej ihned po instalaci vypnout - a to je to špatné. V lepším případě přejdou na systém s AppArmor, kde se cítí tak nějak jako mimo zdi ústavu pro psychicky nemocné.
Jinak je vaše demagogie, jako vždy, brilantní.
ČLÁNKY DO MAILU