systemd 230 a systemd.conf 2016

Po více než třech měsících vývoje od vydání verze 229 (zprávička) oznámil Zbigniew Jędrzejewski-Szmek vydání verze 230 správce systému a služeb systemd (GitHub, NEWS). Lennart Poettering nedávno oznámil, že letošní konference systemd.conf věnována systemd proběhne v Berlíně ve dnech 28. září až 1. října. CFP běží do 1. srpna.

22.5.2016 20:00 | Ladislav Hagara | Nová verze

Komentáře

[Bedňa]

Občas si hovorím či niesom proti systemd nejak zaujatý a preto som primárne proti. Už som zas romýšľal či ho predsa zas netestnem, no po prečítaní changelogu, som zas vytriezvel :) Je to neudržateľné peklo, ktoré svojim návrhom musí skončiť ako Win. Ďakujem Linux enviroment za slobodu kde sa môžem stále rozhodnúť nad tým čo používať budem.

[Harvie.CZ]

Ja si myslim, ze vyvoj je potreba delat v nekolika krocich... Rad to pripodobnuju ke konceptu Trimurti. Shiva - Znicit stary koncepty
Brahma - Vytvorit novy koncepty. Pridat novou sexy funkcionalitu, ktera nalaka k upgradu early adopters
Vishna - Uklidit bordel, Zoptimalizovat to, Zhodnotit zmeny, Doladit API kvuli LTS distrum. Nalaka k upgradu i lidi co potrebujou stabilni system Tj. systemd je momentalne ve fazi brahma. Ale jeste bude potreba hodne vishny. Mozna, ze vishna nastoupi az jako fork

[Bedňa]

Ja zastávam skôr pôvodnú filozofiu slobodného softvéru, zober a vylepši.

Systemd proste zbúral celý Linux enviroment a nasadil jednoliaty blob, ja viem je to rozdelené do viacerých projektov, bohužiaľ ktoré bez seba nedokážu existovať, takže blob to je.

Pokusy o vykostenie systemd len na správu initu tu už boli "uselessd" a skončili s tým že API sa tak rýchlo mení, že to nieje v ich silách adoptovať. Nepodobne postupuje GTK3, takže tu už slobodný kód od uzavretého moc ďaleko od seba nemajú.

Tak kašľať na to, antiX a Devuan fungujú skvelo a KU distro LegacyIce-antiX tiež, tak ešte stále máme šancu prežiť :)

[Michal Sekletár]

Pokusy o vykostenie systemd len na správu initu tu už boli "uselessd" a skončili s tým že API sa tak rýchlo mení, že to nieje v ich silách adoptovať. Nepodobne postupuje GTK3, takže tu už slobodný kód od uzavretého moc ďaleko od seba nemajú.

systemd ma interface stability promise a vacsina APIs, ktore poskytuje systemd je pokryta tymto prislubom a APIs sa nemenia.

https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

[pavlix]

Taky mi to zní spíše jako výmluva. Někoho to přestalo bavit a bylo mu líto všem po tom velkolepém oznámení říct, že na to kašle.

[Bedňa]

Sux it, vyskúšaj si to.

[pavlix]

Tenhle bordel nikdy nikdo neuklidí. Není problém najít příklady projektů, které do fáze úklidu nikdy nedošly.

[deda.jabko]

Tenhle bordel nikdy nikdo neuklidí.

Tenhle bordel nikdy LP neuklidí.

Jakmile si najde novou hracku, systemd poleti do kouta a zacne rozbijet neco jineho. Akorat je mi lito tech lidi z RedHatu, co to budou muset udrzovat, supportovat a opravovat jeste minimalne deset let.

[little.owl]

Akorat je mi lito tech lidi z RedHatu, co to budou muset udrzovat, supportovat a opravovat jeste minimalne deset let.

Litovat je za stabilni zamestnani s vyhledem do budoucna ?

[pavlix]

+1

[AlYoSHA]

No neviem neviem kde vidis tu slobodu. Na systemd prechadzaju v podstate vsetky main distra a zda sa ze na hlasy ktore su proti sa tak nejak kasle. Co dam na servre o 5 rokov? Nechce sa mi drzat vlastnu distribuciu.

[biolog]

Svoboda spočívá v tom, že si se systémem můžete dělat, co chcete. (A můžete to publikovat.) Svoboda neznamená, že kvůli vám někdo hne prstem, např aby zachoval podporu pro váš use-case.

[AlYoSHA]

Naozaj? Dost alibisticke tvrdenie. Jednak vsade okolo pocuvam o moznosti vybrat si a teraz toto Skuste to povedat nejakemi koncovemu uzivatelovi. Moj use-case znesie aj systemd, avsak systemd povazujem za SPF (Single Point of Failure) a pochybujem ze som sam.

[pavlix]

To není alibistické. To je každodenní realita. Svoboda open source skutečně nespočívá v tom, že vám někdo bude plnit přání jako kouzelný džin. To vůbec není o systemd ale o jednom z nejfatálnějších omylů, který se při práci s open source stává.

[lertimir]

Ale možnost si vybrat mají přece všichni. Včetně sestavovatelů distribucí a včetně těch, kteří s jejich výběrem nesouhlasí. A i výsledek výběru je Debian - Devuan. V mém use-case je skutečně jediný bod, který mě s systemd pálí to padání binárního logu při závažném problému. Naopak, když to funguje loguje journald velmi hezky.

[pavlix]

Taky se mi teď složil binární log. To mám asi za to, že se mi myšlenka strukturovaných logů líbí. :)

[lertimir]

Hlavně to je že neexistuje opravný nástroj. Když si člověk uvědomí, co dělá na porušeném textovém logu, tak očima (nebo stringovým searchem) hledá řetězce, které mu připomínají možné řetězce, které by v logu mohly být. A to i za místem, kde je log porušen. A vytěží z něho co jde. V té chvíli, kdy reader binárního logu, narazí na první nekonzistenci a skončí, je to problém, protože když se nepokusí získat, veškeré informace a nalést konzistentní struktury i za místem porušení vypadne toho hodně.

[pavlix]

Já osobně vidím nejlíp postup RHELu, kde se paralelně vytváří i textový log, takže ti zůstane aspoň ten. Ale hlavně vůbec nechápu, jak u mě třeba požkozený log vznikl a hlavně proč se z toho journald sesypal a přestal logovat úplně. Mně osobně na laptopu nezajímal log z doby před požkození, ale vadilo mi, že jsem neměl log z poslední půlhodiny a hlavně jsem nedokázal log během pár minut zprovoznit, aby nahrával informace nové, abych reprodukoval problém se sítí, na který mi stačí provést další pokus o připojení.

Chápu, že jsou v software chyby, ale zase na druhou stranu mi nepřijde, že by zpracování a zápis logů bylo něco tak složitého. Navíc jsem ani nepotřeboval zkoumat uložený log. Kdyby log fungoval v RAM a čas od času zahlásil další neúspěšný zápis na disk, tak neřeknu půl slova.

[j]

S vlastnim barakem si taky muzes delat co chces ... teda do okamziku, kdy tech zdi ubouras moc a on spadne.

Svoboda SW ma spoustu ruznych tvari, a svoboda se hrabet v kodu je jen jednou z nich. Pokud to chces svobodne pouzivat, tak ti systemd tu svobodu bere.

[biolog]

S tím barákem souhlasím. Ale nevidím jak souvisí se systemd. Pottering systémy bourá sobě (podle něj ten bárák zlepšuje), distribuce to přijímají. Uživatelé přijímají distribuce, ale část z nich brblá, že by distribuce měly vynaložit práci na podporu alternativních initů, nebo že by neměly nevynaložit práci na přechod na systemd.

Systemd jen výchozí (nebo jediná) možnost v mainstreamových distribucích. Distribuce ani systemd vám svobodu neberou, nemusíte je používat. Pokud chcete, aby distribuce podporovaly jiné inity, chcete, aby pracovaly pro vás. Pochopitelně to znamená přejít na méně používanou distribuci, ty bývají hůře podporované, což se lidem nelíbí. No jo no, chápu je, ale je to jejich problém.

[Bystroushaak]

S vlastnim barakem si taky muzes delat co chces ... teda do okamziku, kdy tech zdi ubouras moc a on spadne.

To je docela častý omyl. S vlastním barákem si v čechách nemůžeš dělat skoro nic, dokonce je problém i vyměnit okna, když zrovna bydlíš ve špatné části republiky (CHKO a tak). Obecně se dá říct, že skoro na všechno co chceš udělat potřebuješ povolení, jinak z toho hrozí průser (zažil jsem, když jsme vybourali příčku v koupelně a viděla to můra z úřadu oknem, nepřeju nikomu).

[marek_hb]

to ve mě vzbuzuje otázku - proč na to všechna distra přicházejí když je to takový shit?

[Michal Kubeček]

Ze začátku hlavně proto, že většina velkých distribucí - včetně těch, které se tváří jako komunitní - je už dnes vedena manažersky a uživatelská základna nebo drobní přispěvatelé do podstatných rozhodnutí moc mluvit nemohou (OK, mluvit mohou, ale ovlivnit je, to ne). A jestli něco Lennart Poettering umí opravdu dobře, tak je to generování PR, na které manažeři slyší. Takže přestože vývojáři od začátku viděli, že ten projekt ne vedený nezodpovědně, kašle na kompatibilitu s ostatními, kašle na maintenance a ignoruje bugreporty, což je u takhle zásadní součásti systému katastrofa, lidé se skutečnou mocí rozhodovat nad tím mávali rukou jako nad podružnými technickými detaily, které se nějak vyřeší. Skutečnost v mnoha ohledech předčila ty obavy, ale realističtější manažeři krčí rameny, že vlak už jede a nám nezbývá než se zuby nehty držet, méně realističtí dál mávají rukou, že to vlastně všechno funguje úplně skvěle.

Druhý důvod je, že v okamžiku, kdy přešlo nadkritické množství distribucí, začala i řada dalších projektů v upstreamu přecházet na sytemd-only řešení, což znamená, že udržovat distribuci s normálním initem je čím dál těžší. Tomu se dalo předejít, kdyby ti manažeři hned na začátku jasně stanovili, že systemd do distribuce nepůjde, dokud nebude schopen koexistovat s ostatními. Ale to se bohužel nestalo, místo toho se od začátku nastolila politika, že kdykoli změna v systemd něco rozbije, je vždy na tom druhém, aby to nějak vyřešil. Některé projekty jsou si holt rovnější.

[marek_hb]

dík za info

[Ivan2]

Docela me udivuje kam az to muze zajit. Kdyz se podivam na technologii, ktera me zivi: Oracle tak se deji veci ktere se drive proste stat nemohly. V dobe kdy byl Oracle oficialne certifikovan na RHEL 7, neexistoval zadny rozumne pouzitelny duvod jak to vubec na RHEL 7 nainstalovat. Muselo se to resit se supportem. Az dodnes Oracle neresil, jak nahodit a sundat databazi pri startu rebootu. Vzdycky si to musel vyresit (doresit) kazdy admin sam. (Stacilo stahnout 50ti radkovy script z netu a poupravit ho). Teprve se systemd dodava nejaky oficialni navod jak to resit, nekteri Oracle admini to proste nedavaji.

Bohuzel Oracle vydava dokumentaci v tzv. Notes, to jsou oficialni dokumenty, ktere popisuji nejaky konkretni case a bohuzel casto nejsou nijak prolinkovane. Takze kazdy pro "pruser", ktery systemd zpusobi je samostatny jeden dokument. A zatim zadna oficialni dokumentace pro RHEL 7 neni, a spousta veci, ktera drive platila uz se systemd neplati. A s tim jak je to pomala korporace, tak se jim opravdu nedari prepsat veskerou dokumentaci, tak aby byla poplatna pro RHEL7.

Docela by me zajimalo na co narazi treba takove Veritas VCS, tam musi byt ze systemd opravdu nestastni.

[Michal Sekletár]

Docela by me zajimalo na co narazi treba takove Veritas VCS, tam musi byt ze systemd opravdu nestastni.

Veritas Storage Foundation mam momentalne nainstalovane na testovacom stroji a aktualna situacia je velmi zla. Default konfiguracia ako tak funguje, ale je extremne nachylna na chyby. V podstate nie je mozne rozumnym sposobom deklarovat v sluzbe zavislost na dany vxfs mount point, pretoze to sposobi dependency loop alebo timeouty pocas boot-u.

Problem je v tom, ze blokove zariadenie, ktore sa pouziva na mountovanie vxfs je vytvorene z userspace pomocou mknod a udev o nom teda vobec netusi a tym padom o nom netusi ani systemd, co je problem.

Dalsi problem je, ze u Veritas vxfs existuju vzdy dva device nody pre kazdy vxvm disk volume. To moze sposobit problem aj v dalsich nastrojoch, napr. cryptsetup. /dev/vx/dsk/testdg/testvol a /dev/VxVM23000 odkazuju na rovnake zariadenie (199:23000). Toto je dnes relativne nestandardne a vela nastrojov nepocita s tym ze to tak moze byt, pretoze za normalnych okolnosti (e.g. LVM2) existuje vzdy jeden device node a mnozina symlinkov na ten device node.

https://bugzilla.redhat.com/show_bug.cgi?id=1244091

[little.owl]

Neni to az takovy shit a hlavne nemame zatim nic lepsiho, u ceho by stalo za to prekopat distribuce.

[Migi]

Anti-systemd flamewar in 3,2,1

[lertimir]

No já jsem také v poslední době celkem podezřívavý. Pokouším se pomoci kamarádu, že mu zmizely nějaké logy a logování mu nefunguje. a dostal jsem toto:

/var/log/journal/4ed603cd18304c8d9216b69334cdeb3a # journalctl --verify
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1002.journal                                                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00050f6d506c8147-1c96786ffac4ea68.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00050f777ff2e5a4-5b600227840db7dd.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00050f8267ec2260-49ade9d0e99c543b.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@170de817d7674fea96388572452e7ebf-0000000000000001-00050f8266ec5f34.journal                                    
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000000044a-00050e367e6c949b.journal:3aabb0 (of 8388608 bytes, 45%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000000044a-00050e367e6c949b.journal (Bad message)
644b48: Data object references invalid entry at 647b70                                                                                                                       
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000511cf5eb284f9-147169d180a81fe1.journal~:647998 (of 8388608 bytes, 78%).              
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000511cf5eb284f9-147169d180a81fe1.journal~ (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@b13bb2a1d9a64475ba82936af3ebbee4-0000000000000001-000511cf5d1a6076.journal                                    
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000001b46e-0005119707ae2d32.journal:3b8c78 (of 8388608 bytes, 46%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000001b46e-0005119707ae2d32.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@0005149e4264e641-4ed90ba9fccb9438.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1001.journal                                                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@62154eb78c9e455fa16b8392d4bff637-0000000000000001-0005149e3f275de9.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@62154eb78c9e455fa16b8392d4bff637-000000000002b2d2-000517cbd9b514c2.journal                                    
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-0000000000025042-0005141a185d504d.journal:3a2260 (of 8388608 bytes, 45%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-0000000000025042-0005141a185d504d.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@62154eb78c9e455fa16b8392d4bff637-000000000002b440-000517cbdaa67c9a.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@62154eb78c9e455fa16b8392d4bff637-000000000002d505-00051b3e5e476fd6.journal                                    
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000002b43f-000517cbdaa67bac.journal:3980a0 (of 8388608 bytes, 44%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000002b43f-000517cbdaa67bac.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@62154eb78c9e455fa16b8392d4bff637-000000000002d610-00051b3e5f252801.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000002d60f-00051b3e5f25270c.journal                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00051e26f43b6006-0cac73e506a444ac.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@4285b439b8d04ec8b4db63514a985ad0-0000000000000001-00051e26f3905b7a.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000004435a-00051da788ae5526.journal                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000520402adf35d7-a10bb97c7d7d89ed.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e5d2298c0649462e92bab00c67600567-0000000000000001-000520402a31fb95.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-0000000000065887-000520173f383b35.journal                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e5d2298c0649462e92bab00c67600567-000000000007f376-00052205ca597a04.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e5d2298c0649462e92bab00c67600567-00000000000981b8-000522532d41de4a.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e5d2298c0649462e92bab00c67600567-00000000000b38cf-0005259fc3486501.journal                                    
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000009037b-0005220aa4816f4b.journal:447fb8 (of 8388608 bytes, 53%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-000000000009037b-0005220aa4816f4b.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e5d2298c0649462e92bab00c67600567-00000000000b3afa-0005259fc531d0ea.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@b38ebb98badf40d6b12d6536a6c30a7f-00000000000b3af8-0005259fc531cf57.journal                                 
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000009a3fc-0005227b382a1cea.journal:3c7ae0 (of 8388608 bytes, 47%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000009a3fc-0005227b382a1cea.journal (Bad message)
394368: Data object's entry array not sorted                                                                                                                                 
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@0005267a8594bc57-728d895d2baed229.journal~:1375718 (of 25165824 bytes, 81%).            
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@0005267a8594bc57-728d895d2baed229.journal~ (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@0005267a86aa885c-817e3629fece7805.journal~                                                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000527a43628e3ac-d62bd289e191683d.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@000527a43722772d-fe32bc2b06d2c1c5.journal~                                                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@a8010869d1ea4fef98c1e76bd324adf8-0000000000000001-000527a435649419.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@dc9962eb077c45e4b0027adee94eaa9e-0000000000000667-000527a43722ad2d.journal                                 
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1003@2f4df50c26034069996cb5944e32d349-0000000000099bcd-00052253e7dbb424.journal:39c6f8 (of 8388608 bytes, 45%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1003@2f4df50c26034069996cb5944e32d349-0000000000099bcd-00052253e7dbb424.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1003.journal                                                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@a8010869d1ea4fef98c1e76bd324adf8-00000000000c3c46-000527e30e088274.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@dc9962eb077c45e4b0027adee94eaa9e-00000000000c3c99-000527e45aa2b0c8.journal                                 
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-00000000000b3c7c-0005259fe1c95d49.journal:3bcb20 (of 8388608 bytes, 46%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-00000000000b3c7c-0005259fe1c95d49.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1004.journal                                                                                                    
7290f8: Data object references invalid entry at 461d428                                                                                                                      
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000529df50348f10-501962facd73cff2.journal~:4618018 (of 75497472 bytes, 97%).            
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000529df50348f10-501962facd73cff2.journal~ (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@02212dd16dbf411c91a2dd759fec2d0b-0000000000000001-000529df4f7b38c7.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@dc9962eb077c45e4b0027adee94eaa9e-00000000000c7b8b-00052806fc2dae11.journal                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-00000000000c7ade-000528067c24873c.journal                                
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052a8a4a235aa3-6afa7b95ffd5feb7.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@00052a8a4be16e61-75719e0375a3ae44.journal~                                                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052b65a9d25b50-e9eef48d15e245a2.journal~                                                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052ba6e742d4e0-8e29b8a137c507e6.journal~                                                                    
8e9fe0: Invalid entry item (0/22 offset: 000000                                                                                                                              
8e9fe0: Invalid object contents: Bad message                                                                                                                                 
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052bb8fbdf02c9-88cdee460e2c070a.journal~:8e9fe0 (of 16777216 bytes, 55%).             
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052bb8fbdf02c9-88cdee460e2c070a.journal~ (Bad message)
47ce78: Data object references invalid entry at 16c1338                                                                                                                      
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052c1eb79221ce-ad85998ddac9dde7.journal~:16c1118 (of 25165824 bytes, 94%).            
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052c1eb79221ce-ad85998ddac9dde7.journal~ (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e0260d6bc30a4c289d5e7660b632104c-0000000000000001-00052c1eb5fe7ab5.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@141349577ba8491ebc9243d7a5582c25-0000000000000680-00052a8a4be1c45d.journal                                 
000000: Invalid tail monotonic timestamp                                                                                                                                     
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000011f37e-00052a793de93aa5.journal:3ceb50 (of 8388608 bytes, 47%).
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000011f37e-00052a793de93aa5.journal (Bad message)
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@e0260d6bc30a4c289d5e7660b632104c-0000000000161d63-00052cebca04b8e0.journal                                    
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@141349577ba8491ebc9243d7a5582c25-0000000000161d8c-00052cebd23dc909.journal                                                                                                      
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-0000000000161d61-00052cebca04b773.journal                                                                                                     
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00052fa474c716d1-91ce2fd8ba08e2f9.journal~                                                                                                                                         
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@00052fa477b36a01-a75b9a418d595f87.journal~                                                                                                                                      
237fa98: Unused data (entry_offset==0)                                                                                                                                                                                                            
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@000530a1d56f8a83-bdfa11dde0ede8ea.journal~                                                                                                                                         
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@00000000000000000000000000000000-00000000001cef11-000531158f285c89.journal                                                                                                                                                                                
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00000000000000000000000000000000-00000000001cf88e-00053115d3f10323.journal                                                                                                                                                                                   
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@00000000000000000000000000000000-00000000001cfa04-00053115da6b81e8.journal                                                                                                                                                                                
000000: Invalid tail monotonic timestamp                                                                                                                                                                                                                                                                                    
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000019bf05-00052f6ccb94fc04.journal:3eeab8 (of 8388608 bytes, 49%).                                                                                                                         
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-000000000019bf05-00052f6ccb94fc04.journal (Bad message)                                                                                                                                                                 
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000@00000000000000000000000000000000-0000000000000000-0000000000000000.journal                                                                                                                                                                                
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-1000.journal                                                                                                                                                                                                                                                   
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534@a14f45cf06ad42e091a769f14ab4fd2a-00000000001e5ad4-000531db26c7f74e.journal                                                                                                                                                                               
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/user-65534.journal                                                                                                                                                                                                                                                  
a4b0c8: Entry array not sorted at 19250 of 19251                                                                                                                                                                                                                                                                            
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00000000000000000000000000000000-0000000000000000-0000000000000000.journal:1130b80 (of 25165824 bytes, 71%).                                                                                                                           
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@00000000000000000000000000000000-0000000000000000-0000000000000000.journal (Bad message)                                                                                                                                                                     
c8d018: Invalid object                                                                                                                                                                                                                                                                                                      
File corruption detected at /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@0005331ca0bbff17-67e7a7a82169e0f1.journal~:c8d018 (of 16777216 bytes, 78%).                                                                                                                                                            
FAIL: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system@0005331ca0bbff17-67e7a7a82169e0f1.journal~ (Bad message)                                                                                                                                                                                                     
PASS: /var/log/journal/4ed603cd18304c8d9216b69334cdeb3a/system.journal       

Zatím jsem nijak nenašel, že by bylo možné ty logy nějak opravit, aby se neztratily data? Tedy zlatý textové orientovaný log, i když se něco zblblo, tak se z něj informace daly získat. a maximálně vypadla pouze okamžitá část.

[Sid]

Najviac by si mu pomohol asi reportom chyby ak si to uz pravda neurobil

[lertimir]

Já nevím, co se u něj stalo. Report má cenu, když je popsán proces vzniku. A jinak otázek, jestli je možné a jak opravit rozpadlé logy je na netu spousta včetně položek v buzilách.

[Heron]

Tak hodně štěstí. Sám LP v nějakém bugu tvrdí, že se to opravovat nebude. Takže journald je sice povinný, ale stejně je potřeba zapnout forward to syslog a logovat si to pořádně ještě vedle journald.

Vadné logy journald jsou zřejmě vlastnost.

[Lol Phirae]

Vadné logy journald jsou zřejmě vlastnost.

Viz. #facepalm

[j]

Externi loger je ti na kulovy, pokud to tu msg nezvladne zapsat do vlastniho logu, tak ji to zcela 100% ani nepreda.

[little.owl]

Coz IMHO neni pravda. Jinak poruseni integrity dat jsem mel i u syslog/rsyslog, realita je takova, ze kdyz se system hrouti, muze stahnout jakykoliv logger. journalctl se v pripade korupce logu vicemene chova korektne.

[j]

Jenze kdyz se ti zhrouti textovej log, tak si 99,9% toho textu vpohode prectes. Mozna tam nebudes mit zalogovany to, co k padu vedlo, ale muzes se podivat, co se delo predtim.

A IMO to pravda je, protoze ty ten dalsi logger muzes navazat az na to, co dela tenhle systemd shit. Takze sice hypoteticky muzes nekde mit tu textovou variantu, ale klidne se ti muze stat, ze tam 1/2 logu chybi proste proto, ze se logger systemd prave posral (coz je jeho defaultni stav).

[lertimir]

Hm. Tak když jsem se před nedávnem rozohňoval nad arogancí vývojářů, tak tady už to ani nemá cenu. Podle mého zastaralého názoru má být log z principu postaven tak, aby se nemohl pos**** nikdy, nebo skoro nikdy, když má kde psát.

[j]

Posrat se muze, ale minimalne mas (na distrech ktery jeste zustaly pri smyslech) moznost si vybrat z hromady ruznych, podle potreb. Chces logovat do databaze? Proc ne. Chces podporu regularnich vyrazu? OK ...chces cojavim .. logovat v XML? Zadnej problem. A kdyz si vzpomenes na nejakou brikuli ... tak si k tomu snadno prilepis vlastni tool, kterej bude delat co chces TY.

V kazdym pripade kdyz tvurci reportnes, ze se log rozesira a je necitelnej, tak to bude jeden z bugu, ktery bude nejspis resit hned, protoze jaksi rozjebanej log u demona co ma jen logovat, je celkem podstatna zavada ... kdezto rozjebanej log u systemd je nezajimava vlastnost ...

[Lol Phirae]

To, že se ta binární logovací sračka hroutí, je léta známý problém -- a Lennartova rada je log smazat. Reportování je úplně zbytečné.

[Bystroushaak]

          systemd-logind will now by default terminate user processes that are
          part of the user session scope unit (session-XX.scope) when the user
          logs out. This behavior is controlled by the KillUserProcesses=
          setting in logind.conf, and the previous default of "no" is now
          changed to "yes". This means that user sessions will be properly
          cleaned up after, but additional steps are necessary to allow
          intentionally long-running processes to survive logout.

          While the user is logged in at least once, user at .service is running,
          and any service that should survive the end of any individual login
          session can be started at a user service or scope using systemd-run.
          systemd-run(1) man page has been extended with an example which shows
          how to run screen in a scope unit underneath user at .service. The same
          command works for tmux.

          After the user logs out of all sessions, user at .service will be
          terminated too, by default, unless the user has "lingering" enabled.
          To effectively allow users to run long-term tasks even if they are
          logged out, lingering must be enabled for them. See loginctl(1) for
          details. The default polkit policy was modified to allow users to
          set lingering for themselves without authentication.

          Previous defaults can be restored at compile time by the
          --without-kill-user-processes option to "configure".

Boží.

[lertimir]

Proboha.

[Lol Phirae]

Super nápad. A nejlepší je ten popis rovnáku na vohejbák se screen-em a tmux-em.

[Bystroushaak]

Já vážně uvažuju co s tím. Tohle je jako dostat facku a prostě mě nebaví být fackován.

[Ondrej Santiago Zajicek]

Já vážně uvažuju co s tím.

Proste nepouzivat systemd? Jde to ;–)

[Bystroushaak]

Ano, a součást úvah „co s tím“ je právě jak na to, aby to moc nebolelo. Například na serverech jsem měl všude ubuntu, protože to byla docela bezstarostná distribuce, ale výhledově asi budu muset přejít na něco jiného.

[Vantomas]

No jo, ale když to rozbijou v upstreamu (výchozí hodnota v systemd), tak pořád to můžou opravit v distribuci (vypnutí výchozí hodnoty v systemd). Co mít trochu důvěry v tento proces?

[Bystroushaak]

Nejsem admin. Chci něco, co je funkční a bude to (stejně) fungovat i za 10 let, ne řešit (z mého pohledu) blbosti a spoléhat na to, že možná někdo někde něco narovná, po tom co to někdo někde jinde ohnul. Uznávám, že jsem si asi špatně vybral distribuci a taky si na ní neštěžuji.

Zatím nikam nepřecházím, ale pocit nespokojenosti dlouhodobě narůstá. V určitou chvíli to prostě bylo (z mého pohledu) perfektní a teď jde má (subjektivní) spokojenost jen dolu, protože mě různí divní lidé nutí věnovat se věcem, kterým se věnovat nechci.

[AsciiWolf]

a bude to (stejně) fungovat i za 10 let

Tohle imho v případě GNU/Linuxu nikdy moc neplatilo.

[Michal Kubeček]

Napadají mne dvě firmy, které na takové poptávce mají založený svůj business… :-)

[AsciiWolf]

Jasně, u enterprise distribucí je situace trochu odlišná. Měl jsem na mysli spíš vývoj GNU/Linuxu obecně, který nikdy nebyl nijak zvlášť konzervativní.

[Bystroushaak]

Tohle imho v případě GNU/Linuxu nikdy moc neplatilo.

Nemusí to být úplně stejně, ale mělo by to být stejně z pohledu mého uživatelského zážitku. Je mi jedno, že se změní implementace, měl by ale zůstat podobný interface.

Například je mi úplně jedno, jestli někdo zrychlí bootování, nebo přidá lepší konfigurák na služby. Když ale za pár let zjistím, že mi neběží aplikace a že nevím, jak spustit internet, protože se změnila půlka toho, co jsem znal, tak to považuji za špatnou časovou investici.

[trekker.dk]

Výsledkem toho procesu je, že ta věc je výchozí a většinou taky jediný init systém, který distribuce podporuje. Další důvěra není na místě.

[mirec]

Nie je práve ubunťácky upstart dosť blízky systemd? (teda až na drobnosť, že nepožral všetko čo je v okolí)

Ja spravujem zopár strojov a najradšej mám práve tie s ubuntu kvôli deklaratívnej syntaxi daemonov na rozdiel od tých príšerností v debiane. Systemd som zatiaľ na žiadnom serveri nepoiužíval, ale chystám sa jeden debian aktualizovať. Nemyslím si, že systemd môže byť horší než tá príšernosť, ktorá tam je teraz.

[Michal Kubeček]

Nevím, čím to je, ale vybavil se mi Svěrák s kosou, jak se uchechtává.

[Bystroushaak]

Ja spravujem zopár strojov a najradšej mám práve tie s ubuntu kvôli deklaratívnej syntaxi daemonov na rozdiel od tých príšerností v debiane. Systemd som zatiaľ na žiadnom serveri nepoiužíval, ale chystám sa jeden debian aktualizovať. Nemyslím si, že systemd môže byť horší než tá príšernosť, ktorá tam je teraz.

To proto, že systemd vnímáš jen jako systém na spouštění služeb. Jenže ta sračka už je všude, od sítí po správu programů co běží po odhlášení uživatele.

[mirec]

Je to možné, mám o ňom minimálne informácie, viac-menej z diskusií tu a na root.cz. Viem, že ľudia vždy nadávajú na nové veci, takže to beriem s rezervou a verím, že to nebude až také zlé. V bývalej práci som mal arch linux, áno uznávam, že tam systemd nefungoval ideálne (asi 50% pravdepodobnosť, že nabootuje, zvyklo sa to pri boote na niečom náhodne seknúť a vyradilo mi to dovtedy fungujúce wake on lan keďže som nadiaľku mohol nabootovať so šancou asi 50%), ale od vtedy prešlo veľa času, takže verím, že je to teraz už OK. Áno som optimista

[rastos]

To vynašiel nohup?

[AsciiWolf]

Yo dawg we heard you like nohup...

[Josef Kufner]

Zrovna tohle mi nepřijde vůbec mimo. Nějaký čas nazpět mi běžně po odhlášení zůstávaly běžet procesy, které pak při opětovném přihlášení dělaly bordel, takže jsem se pak musel v konzoli přihlásit ještě jednou a pozabíjet to ručně. Shell tohle řeší rozesíláním SIGHUP, což ale není úplně dostačující v X Window, kde spousta věcí běží mimo shell i terminál.

Programy jako screen, tmux a nohup můžou dostat podporu systemd celkem rychle. Je vůbec ještě nějaký use-case, krom těhle tří nástrojů, kdy má proces přežít session?

[hkmaly]

Programy screen, tmux a nohup meli mit podporu systemd predtim nez to prepnuli. Pokud ji dodelaji ted tak uz to bude pozde. Neco exotickeho prosim, ale tyhle tri jsou naprosto lozene.

[Václav "Darm" Novák]

Nová verze systemd se stejně dostane jako první do bleeding edge distribucí. Kde člověk s tím že se občas něco lehce rozbije počítá. Než se to dostane do stále distribucí, mohou být dané nástroje dávno opraveny.

[MIke]

Bohužel, systemd možná ze začátku nebyl špatnej nápad, ale musel by to dělat někdo normální. Aktuálně se chyby neopravují, jsou prohlašovány za vlastnost a ještě nám do očí tvrdí, že je ta vlastnost dokonalá a má to tak být. Takový dodrbaný logy - není lepší, když se log v případě problému nedá přečíst? Taková otravná práce pro admina... jděme na to po windowsowsku, když se něco podělá, přeinstalujeme OS. Když to nepomůže, koupíme nový železo. A že kvůli nefunkčnímu systému stojí pár set lidí a nemůžou pracovat? SUPER! Práce je přece otrava, můžou jít na pivo! Ve výsledku z toho může být hromada spokojených zaměstnanců a pár nespokojených kravaťáků - a to se vyplatí :)

[Josef Kufner]

Tak to u systemd už je celkem normální, na to si už snad všichni okolo zvykli a nenasadí čerstvou verzi hned.

[Heron]

Mě u těchto změn chybí nějaké podívání typu: "Dělali jsme to z toho a z tohoto důvodu a vidíme v tom ty a ty výhody. Pokud chcete používat staré řešení, nastavte si tohle, ale zvažte také výhody nového řešení. Tady jsou ukázky staré vs nové."

U systemd nic takového není. Prostě něco starého zboří a k novému řešení není kromě manu napsáno prakticky nic. Tohle kdysi krásně vystihl Michal Kubeček u nějaké změny ve Firebirdu. Přidali tam nějakou vlastnost, důkladně ji popsali včetně výhod a nevýhod a Michal to okomentoval slovi: "Považovali za nutné to uživatelům vysvětlit". Borci v systemd nepovažují za nutné cokoliv vysvětlovat.

[Josef Kufner]

Jo, s tím naprosto souhasím. Ale chtělo by to tohle poslat do jejich mailing listu, tady si to nepřečtou.

[j]

Mno ... tam to tak maximalne smazou.

[mankind_boost]

lol, takhle systemd gang nefunguje, ti ti tak maximalně daj ban

[pavlix]

Potvrzuju. Už mě málem vykopli ze systemd IRC kanálu, když jsem radil někomu, komu tam poradit odmítali. Asi jinej gang.

[Lol Phirae]

Tys jim určitě radil něco ideologický závadného, třeba jak se toho Lennartova pokladu zbavit. :-P

[pavlix]

Ani ne. Sice už si to přesně nepamatuju, ale šlo o řešení požadavku, který oni považovali za špatný nápad.

[Michal Kubeček]

A aby toho nebylo málo, kluci od systemd taky nedávno usoudili, že 4096 processes should be enough for anybody, tak to pro jistotu nastavili jako globální default. (OK, abychom byli féroví, později se nechali přemluvit a zvedli to na 12288.)

[j]

To zacina bejt cim dal vetsi prca ... ;D dovozuju z toho, ze systemd je urcen na jednoprocesorovej jednojadrovej stroj. Holt si ti, co si poridej par tisic procaku, budou muset nainstalit widle ...

[Michal Kubeček]

Tak zlé to není, ta hodnota naštěstí jde v konfiguraci změnit (i na nekonečno), ale je zábavné, že se prostě podívali z okna a nahodili globální default, který je výrazně menší než hodnoty příslušného resource limitu obvyklé v distribucích. Mimochodem, jestli jsem to dobře pochopil, pro služby je teď default 512, s čímž se pro enterprise nasazení narazí ještě rychleji.

[Ivan2]

Tak to je plne jak na windows. Tam je limit pameti pro desktop aplikace 3GB. A pro sluzby 512MB. Vypadato, ze vetsina veci okolo systemd se toci okolo desktopu, a pak se to priohyba pro servery.

[little.owl]

Tam je to limit, zde je to hodnota, kterou uzivatel muze zmenit.

[Ondrej Santiago Zajicek]

Akorat se mi vybavil defaultni kerneli limit pro velikost IPv6 routovacich tabulek (/proc/sys/net/ipv6/route/max_size, taky 4096), ktary je nekolikrat mensi, nez aktualni pocet IPv6 rout v globalnim internetovem routingu.

[Michal Kubeček]

defaultni kerneli limit pro velikost IPv6 routovacich tabulek (/proc/sys/net/ipv6/route/max_size)

1. tohle je hodně nepřesná interpretace té hodnoty.

2. Jak si můžete snadno ověřit, ta defaultní hodnota je stejná už od počátku gitu (2.6.12) a dost možná už od okamžiku, kdy se ta proměnná poprvé objevila. To, že pro některá specifická nasazení nedostačuje a je potřeba ji zvýšit, je úplně něco jiného, než když najednou někdo stanoví umělý limit na počet procesů uživatele, který je řádově menší než hodnota příslušného resource limitu, na kterou do té doby byli uživatelé zvyklí (a která způsobuje podivné regrese projevující se např. překvapivě nízkými výsledky nějakého benchmarku).

3. To, že je defaultní hodnota takto nízká, bohužel není samoúčelné. Praxe ukazuje, že výrazné zvýšení toho limitu může způsobit víc škody než užitku. Souvisí to s nepříliš optimální implementací IPv6 FIB a není to problém, který by se dal triviálně vyřešit za odpoledne.

[little.owl]

než když najednou někdo stanoví umělý limit na počet procesů uživatele, který je řádově menší než hodnota příslušného resource limitu,

Jedna vec implementacni limit a druha vec je prakticka realita v techto pripadech. Scheduling procesu a threadu v Linuxu ma dosti problemu sam o sobe a pokud mate aplikace, ktera vam spousti tolik procesu, ze narazite na limit, bude adminstrator nucen sahnout i na jina nastaveni, takze zmena jedne hodnoty navic nehraje roli.

[Michal Kubeček]

V tom případě je zajímavé, že třeba u nás se na to přišlo tak, že jeden benchmark najednou začal vykazovat podezřele nízké výsledky právě proto, že nemohl vytvořit tolik procesů jako dřív.

[Josef Kufner]

Tak zrovna benchmark není příliš reprezentativní příklad.

[Michal Kubeček]

Nic takového jsem také netvrdil. Reagoval jsem na náznak, že ta hodnota 4096 je vlastně zvolena rozumně, protože nás chrání před problémy s implementací linuxového scheduleru. Pokud jejím zvýšením nejen nenarazíme na takové problémy, ale naopak dosáhneme výrazně lepších výsledků, těžko věřit, že je to omezení nastaveno na hodnotu odpovídající takovému vysvětlení.

[little.owl]

Reagoval jsem na náznak, že ta hodnota 4096 je vlastně zvolena rozumně, protože nás chrání před problémy s implementací linuxového scheduleru.

To jsem ale netvrdil. Rikam, ze pokud na Linuxu zacnete spoustet velke mnozstvi procesu, budete nucen nastavit u rady aplikaci vice parametru.

[trekker.dk]

A jak to tedy souviselo s diskuzí o tom, že výchozí limit v systemd je nesmyslně nízký?

[little.owl]

Defaultni per-user limit 12k vam prijde s ohledem na maximalni defaultni pocet procesu v Linuxu jako nesmyslne nizky?

[trekker.dk]

Když už diskutujete, pokuste se věnovat pozornost jak tématu, tak tomu, co už bylo řečeno. Hodnota, o které se tu diskutuje, je 4096.

[little.owl]

Lennart kdyz zjistil, ze jsou aplikace kde to dela problemy hodnotu bez problemu rychle zmenil. Ostatne i 4096 je nad urovni soft limitu, ktere treba na CentOS 6 byly tusim 1024 a pokud jsem spoustel Docker ci Mongo ci podobne zvrhlosti, musel jsem defaultni hodnotu menit - a vubec jsem necitil potrebu nekomu kvuli tomu spilat .

[Michal Kubeček]

To je pro mne trochu překvapením, jak v openSUSE, tak ve SLE je hodnota toho resource limitu řádově větší.

[little.owl]

Nevim, mozna ochrana proti fork bombam ...?

[lertimir]

Podíval jsem na některé systémy, kam vidím, a Centos 6 má 16 384, openSUSE 13.2, openSUSE Thumbleweed, Debian Wheezy a Jessie, Ubuntu Xenial server všichni 4096. Na žádném systému se nezasahovalo do default konfigurace, co vím.

[Michal Kubeček]

Já na openSUSE 13.1 na jednom stroji vidím 63401, na druhém 255031 a na 13.2 62345. Tumbleweed, tam už je systemd s tím omezením přes cgroups, takže ten není moc relevantní pro diskusi o tom, jak to bylo dřív.

[little.owl]

CentOS 6 ma limit 1024 nastaveny v /etc/security/limits.d/90-nproc.conf a soude podle tohoto reportu ke zvyseni defaultniho limitu nedoslo.

[lertimir]

máš pravdu, že

cat /etc/security/limits.d/90-nproc.conf 
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.

*          soft    nproc     1024
root       soft    nproc     unlimited

ale

 cat /proc/sys/net/ipv6/route/max_size
16384

A žádné zásahy jsem nedělal.

[pavele]

CentOS 6 i 7 má limit 1024, musel jsem ho zvedat kvůli Sambě.

[little.owl]

IMHO, CentOS 7 se systemd ma uz 4096.

[Michal Sekletár]

Mimochodem, jestli jsem to dobře pochopil, pro služby je teď default 512, s čímž se pro enterprise nasazení narazí ještě rychleji.

Prave dnes so riesil poziadavok na backport tejto funkcionality do RHEL7/CentOS7. Bohuzial RHEL7 kernel zatial nepodporuje pids cgroup controller, a teda je potreba backportovat najprv ten. A nemajte strach, v pripade RHEL/CentOS si dame majzla a default bude infinity.

[little.owl]

Bohuzial RHEL7 kernel zatial nepodporuje pids cgroup controller, a teda je potreba backportovat najprv ten.

A tlaci dosti zakazniku, aby se to udelalo?

[Michal Sekletár]

A tlaci dosti zakazniku, aby se to udelalo?

IIRC tak to bol niekto z Ceph filesystem teamu, i.e. interny zakaznik, teda netlaci na to vyslovene nikto. Ostatne, ten backport by mal byt relativne bez problemov, kernel patch ktory pridava podporu pre pids cgroup controller ma cca 300 riadkov, fwiw,

http://article.gmane.org/gmane.linux.kernel/1900680

[little.owl]

Myslel jsem si, ze je to slozitejsi.

[Michal Kubeček]

To by mi přišlo jako nejrozumnější řešení. Co jsem se díval, u nás to bohužel spíš vypadá, že se přidá ten commit, který to zvedá na 12288, a upozornění do Release Notes.

[Bystroushaak]

systemd developer asks tmux (and other programs) to add systemd specific code

Tak se na to musí.

[Lol Phirae]

Čůrák vymrdanej.

[little.owl]

tmux ma uz plno system specifickeho kodu, od Linuxu pres FreeBSD ci OpenBSD po Darwin, HPUX ci SunOS.

[Lol Phirae]

Ano. Takže, abychom "vyřešili" regresi v Gnome způsobenou domrvrním dbus-u, tak začneme v systemd defaultně zabíjet všechno, co běží pod daným uživatelem při odhlášení. A budeme přidávat nesmyslný kód do tmux-u, screen-u a dalších věcí, které s původním problémem absolutně nesouvisejí.

Super myšlenka.

[little.owl]

Tohle nesouvisi s Gnome. Koncept, ze by default uzivatele nenechavaji po odlogovani bezici procesy na pozadi je korektni.

[Michal Kubeček]

A desítky let přesně k tomuto účelu sloužil signál HUP, který defaultně způsobil zabití procesu. Proces, který z nějakého důvodu měl odhlášení přežít, tento signál ohandloval a všechni byli spokojeni. Jenže pak přišli chlapci od systemd se svou doktrínou, že všechno, co fungovalo a na co byli vývojáři i uživatelé zvyklí, se musí bezpodmínečně rozbít (a dodatkem, že když systemd něco rozbije, je to axiomaticky vina toho druhého a na tom druhém je, aby to nějak vyřešil).

[little.owl]

Komicke je ze nohup vzniknul jako odpoved na SIGHUP, ktery take ve sve dobe rozbijel persistentni procesy. SIGHUP neni reseni, jednak muze byt ignorovan a jednak plno veci bezi mimo terminal/shell. Stavet bezpecnost systemu na predpokladu, ze uzivatelem spoustene procesy jsou 'vychovane' a 'poslouchaji', je velmi naivni.

[Michal Kubeček]

SIGHUP neni reseni, jednak muze byt ignorovan

A o to právě jde.

predpokladu, ze uzivatelem spoustene procesy jsou 'vychovane' a 'poslouchaji'

To není o vychovanosti ani poslouchání. Defaultní reakce je ukončení. Pokud program z nějakého důvodu má běžet dál, pak ten signál ignoruje nebo handluje po svém. Jednoduché, prosté, funkční - a právě proto nepřijatelné pro "moderní" svět podle systemd. Tam se musí místo toho někomu poslat zpráva přes D-Bus.

[little.owl]

Reseni postavene na SIGHUP rozhodne funkcni a spolehlive neni, a casto to ani neni vubec reseni. Znovu - novy koncept je IMHO zcela korektni - po odlogovani uzivatele se by default procesy spolehlive ukoncuji, pokud uzivatel potrebuje neco spoustet na pozadi a admin mu to povoli, necht se to spusti kontrolovane jinym zpusobem.

[Michal Kubeček]

po odlogovani uzivatele se by default procesy spolehlive ukoncuji

Stejně jako dosud.

pokud uzivatel potrebuje neco spoustet na pozadi … necht se to spusti kontrolovane jinym zpusobem

Dosud bezproblémově řešeno tím, že dotyčná aplikace ohandlovala nebo odignorovala HUP.

a admin mu to povoli

Což šlo hravě implementovat tím, že pokud má dotyčný uživatel nastaven "odstřel všechno, i to, co nechce", po nějakém timeoutu se procesy, které nezabil HUP, odstřelí pomocí TERM a KILL. Vůbec nebylo potřeba kvůli tomu nutit všechny přepisovat aplikace a nástroje, které desítky let fungovaly k obecné spokojenosti, na nesmyslné a zbytečné hrátky s D-Busem.

A v neposlední řadě: i když už se někdo mermomocí rozhodl (opět) ignorovat zavedené zvyklosti a ukájet své ego tím, že zbytečně předělá svět, ve slušné společnosti je zvykem jako default použít stávající chování. Jako mnohokrát předtím, systemd boys opět ukázali, že slušné chování je jim naprosto cizí.

[biolog]

pokud má dotyčný uživatel nastaven "odstřel všechno, i to, co nechce", po nějakém timeoutu se procesy, které nezabil HUP, odstřelí pomocí TERM a KILL.

No ale takhle to bude fungovat i v systemd. Teda místo TERM a KILL použije control grupy (aby proces nestihl nestřeženě zplodit potomka).

[Michal Kubeček]

Tam to ale bude default a místo (kromě) ohandlování HUP budou muset procesy, které mají odlogování přežít (screen, tmux, nohup, …), provádět zaříkávání přes D-Bus. Úplně zbytečně a úplně nesmyslně.

[Lol Phirae]

Tak určitě. Řekla to jeho svátost Lennart a o tom se prostě nediskutuje. Že tím rozbijeme desítky let fungující věcí typu screen, tmux a kdoví co dalšího, na to přece mrdá pes.

[little.owl]

I v minulosti se musely upravovat, tak jak se systemy na kterych bezely vyvijely, tedy v tomto smeru zadna velka zmena.

[Lol Phirae]

Zbytečná debata. LP a spol. vědí lépe než uživatel, které procesy mají na počítači běžet. Halelujah, slyšeli jste slovo boží.

[Heron]

Je někde povídání o těchto "korektních" konceptech?

Ptám se vážně. Tento bug se mi zrovna trefil do rány, řešil jsem, jak správně automaticky spouštět tmux při startu (nebo alespoň při prvním loginu), nakonec jsem skončil u user service a nastavení linger pro mého uživatele. Toto zdá se funguje.

Ale ani při čtení všech těch bugů ani nikde jinde jsem nenarazil na návrh, do jakého stavu celé to snažení míří (alespoň mlhavě, ve formě představ). To opravdu mění zaběhlé chování systemu salámovou metodou a ještě jen formou bugreportů?

Navíc o tom, zda je to korektní koncept se dá diskutovat. Proč by po ukončení nějakého procesu (třeba ssh) mělo být korektní zabití všech procesů stejného uživatele? Ano, dovedu si představit systém, kde to takto platí, ale my tady máme systém, kde to takto neplatilo. V nějakém z těch bugreportů to kdosi popsal správně. tmux nedělá nic jiného, než že volá daemon. Prostě se z něj stane proces běžící na pozadí (odpojený od terminálu) úplně stejně, jako u ostatních procesů, kterým říkáme služby (ty přece také vznikly jako daemon nějakého uživatelského procesu). A změna konceptu, kdy se některé služby budou automaticky zabíjet a jiné služby ne, je natolik velká, že to podle mě nelze odbýt patchem mezi verzemi 229 a 230.

[Michal Kubeček]

Proč by po ukončení nějakého procesu (třeba ssh) mělo být korektní zabití všech procesů stejného uživatele?

IIUC jen těch, které byly (přímo nebo zprostředkovaně) spuštěny v rámci té session. Kdyby to zabíjelo všechny procesy daného uživatele, to by bylo opravdu postavené na hlavu (napadá mne třeba přihlášení přes ssh na stroj, kde mi zároveň běží celá KDE session se spoustou programů).

[Heron]

No hovoří se o úklidu po odhlášení uživatele z daného stroje. Takže po ukončení všech jeho "login" procesů. Takže pokud si na tom ssh vytvoříš nějaký nohup nebo daemon proces, tak po odhlášení z toho KDE (pokud je to poslední login na daném stroji) ti to zabije i ten proces, který jsi pustil z toho ssh.

Já to testoval jen na terminálu pomocí ssh a zdá se, že je to tak, že pokud je uživatel alespoň jednou přihlášen, tak jeho procesy běží, ale jakmile ukončí poslední spojení, tak to zabije všechno.

[Michal Kubeček]

Fujtajbl… já si celou dobu naivně myslel, že každá session běží v samostatné cgroup a při ukončení konkrétní session se zabije všechno, co do ní patří. Tady je vidět, jak je naivní myslet si, že něco je tak velká pitomost, že by to ani vývojáři systemd neudělali.

[Heron]

I když v manu je to popsáno tak, jak píšeš. Tak nevím.

KillUserProcesses=

Takes a boolean argument. Configures whether the processes of a user
should be killed when the user logs out. If true, the scope unit
corresponding to the session and all processes inside that scope
will be terminated. If false, the scope is "abandoned", see
systemd.scope(5), and processes are not killed. Defaults to "yes",
but see the options KillOnlyUsers= and KillExcludeUsers= below.

Každopádně otázka zůstává, kam systemd míří a jak to dělat the systemd way.

[trekker.dk]

Jen tak ze zvědavosti, neví někdo, jak moc je systemd odolné vůči příčetnosti? Ne, že by to bylo nějak systémové, ale napadl mě proti těmhle blbostem workaround - systemd spustí službu (třeba runsvdir), ta se double-forkne a přesune svoje pid do kořenové cgroup tak, aby systemd nevidělo na další potomky a nehrabalo na ně. Otázka je, jestli tam nemají nějakou kontrolu, která jednou začas tu kořenovou cgroup proleze a všechny takové procesy pochytá.

[Michal Kubeček]

neví někdo, jak moc je systemd odolné vůči příčetnosti?

IMHO velmi. :-)

[Filip Jirsák]

Já to testoval jen na terminálu pomocí ssh a zdá se, že je to tak, že pokud je uživatel alespoň jednou přihlášen, tak jeho procesy běží, ale jakmile ukončí poslední spojení, tak to zabije všechno.

Takhle to podle mne má fungovat. Jde o to, aby to nebylo závislé na tom, jakým způsobem jsem přihlášen. Když se přihlásím z terminálu, přes SSH nebo z GUI (a více způsoby najednou), mělo by to být z hlediska mnou spuštěných aplikací rovnocenné. Mělo by se to chovat tak, že jsem několika cestami připojen k jedné session – a teprve když se poslední připojení ukončí, ukončí se i má uživatelská session.

[Filip Jirsák]

V nějakém z těch bugreportů to kdosi popsal správně. tmux nedělá nic jiného, než že volá daemon. Prostě se z něj stane proces běžící na pozadí (odpojený od terminálu) úplně stejně, jako u ostatních procesů, kterým říkáme služby (ty přece také vznikly jako daemon nějakého uživatelského procesu). A změna konceptu, kdy se některé služby budou automaticky zabíjet a jiné služby ne

Že je koncept daemonů špatně tvrdil už před dvaceti roky Daniel J. Bernstein, a nemyslím si, že byl první. Podle mne cílem není nějaké daemony automaticky zabíjet a jiné ne, cílem je zbavit se všech daemonů, tak, aby všechny služby měly rodiče, který se o ně stará, a jejich standardní výstup aby byl logován (pokud se neřekne jinak).

[deda.jabko]

cílem je zbavit se všech daemonů, tak, aby všechny služby měly rodiče

Rozumim tomu dobre, ze pokud chci mit nejaky neinteraktivni vypocet, ktery bezi v radu hodin nebo dnu, tak nejlepsi postup podle systemd je vytvorit to jako sluzbu, misto obycejneho nohup ./vypocet > vystup.dat?

[Heron]

nejlepsi postup

V manu systemd-run je:

systemd-run --scope --user screen

a pokud člověk nechce, aby mu to systemd zastřelil při odhlášení, tak je potřeba nastavit vlastnost linger (loginctl enable-linger).

Nebo místo volání systemd-run si přímo vyvořit user service a zapínat si to systemctl --user start moje.service.

Jestli jsou to 1) řešení a 2) nejlepší řešení a 3) systemd řešení jsem se zatím nedozvěděl.

[Lol Phirae]

Že je koncept daemonů špatně tvrdil už před dvaceti roky Daniel J. Bernstein

Ano, tento zneuznaný magor a průkopník NIH syndromu je tím ideálním vzorem.

Podle mne cílem není nějaké daemony automaticky zabíjet a jiné ne, cílem je zbavit se všech daemonů, tak, aby všechny služby měly rodiče

Zkuste s Lennartem radši statného ošetřovatele, rodiče už selhali.

[tacoberu]

Podle mne cílem není nějaké daemony automaticky zabíjet a jiné ne, cílem je zbavit se všech daemonů, tak, aby všechny služby měly rodiče, který se o ně stará, a jejich standardní výstup aby byl logován (pokud se neřekne jinak).

Tak ta úvaha je celkem hezká. Ale jak se to liší od stávajícího stavu? Cožpak můžeš mět nějaký proces, který nemá rodiče (krom PID1)?

[Filip Jirsák]

Můžu mít proces, který se o potomky vůbec nestará a je mu jedno, co se s nimi děje.

[pavlix]

Život je pes.