ona nejcastejsi situace je ze: mam 1 sitovou kartu, je mi jedno kam ji zapojim, zda bude interni nebo externi...
chci aby se vzdy jmenovala stejne, takze co udelam?
=> ano tu "genialni" predikci proste vypnu pomoci net.ifnames=0 kernel parametru...
kdyz vymenim kartu upravim si sam podle sebe pravidla pojmenovani dle MAC v /etc/udev/rules.d/70-persistent-net.rules, tedy JEN pokud sem si ho predtim sam vytvoril, pokud ne, neresim nic - automaticky se jiz nevytvari...
resp. nejen s 1 kartou, delam to takto i kdyz mam 10 ethernet sitovek ;-)
Aha tak to je ten druhý případ, kdy riskuješ, že se ti čas od času některé síťovky budou jmenovat ve stylu rename_eth2, protože došlo k souběhu během jejich přejmenování. Ale je z toho snadná pomoc, která navíc ušetří i psaní – síťové karty přejmenovávat na et0, et1,… nebo v zásadě cokoli jiného, jen ne eth a podobná slova, která přiděluje jádro.
To je přesně ten problém souběhu. Někomu se to nestane nikdy za život, někomu se to bude stávat pětkrát do roka a někomu každý den – záleží totiž na mnoha faktorech.
A teď si představte programátora, kterému uživatelé reportují problém a on ho u sebe není schopen reprodukovat, protože zrovna patří do té šťastnější části populace. Jak má takový problém opravit? Je potom jasné, že raději navrhne něco, co takový souběh zcela vylučuje, byť za cenu porušení zpětné interoperability.
Aha tak to je ten druhý případ, kdy riskuješ, že se ti čas od času některé síťovky budou jmenovat ve stylu rename_eth2, protože došlo k souběhu během jejich přejmenování.
Co si pamatuju, tak tohle se stávalo hodně dávno a jen v tom případě, že už bylo něco nastaveno a přišlo se s novou síťovkou, která se bila s původním nastavením. U čistého nikdy a i ten souběh velmi rychle v některé z novějších verzí udev upravili a pak už se to nevyskytovalo nikdy.
A komu nestačí to co umí pravidla udev, tak se od nepaměti dá použít již výše zmíněná utilita ifrename, která fungovala daleko dříve než vůbec někoho napadl udev neřkuli systemd. Bonusem navíc je, že ifrename umí přejmenovávat/pojmenovávat podle hromady jiných kritérií. Když admin není klikoš a své kroky si předem promýšlí, dá se to lehce nachystat dopředu a po upgrade/změně/výměně (whatever) nastartuje v novém tak, že vše jede jak má rovnou a nemusí se koukat, jakpak se přejmenovaly nepředvídatelně síťovky podle křišťálové koule integrované v systemd. Protože největší potíž s tou věcí v systemd je, že tvrdí (stejně jako někteří tady v diskuzi), že když uděláte změnu (přidáte síťovku třeba), tak že se s původníma nic nestane a budou mít stejný název, což je ale z praxe mnohokrát ověřeno, že to není pravda.
Takových pastí je v systemd více, bezvadný je třeba ten timeout na ukončování služeb při shutdown/reboot. Když jsem tu kdysi někde psal, že to nefunguje, byl jsem přesvědčován, že to ne naopak jasně definovaná věc, která nikdy rozbitá nebyla a jediné co je jinak, že ten timeout je ve výchozím nastavený 90 s, což může být zbytečně dlouho. Byl jsem přesvědčován, jak jsem blbej a že s tím neumím ap. Zrovna dneska jsem opakovaně ukazoval kolegovi, jak si ten drzý systemd je schopen ten timeout zvedat, když se odpočet přiblíží té 1:30 min a najednou je třeba čekat 2 min nebo 3 a tak furt dál. A ne prvního dubna ten komp nastavený neměl.
Semantika SIGHUP (teda to, co riesi tmux, screen, et al) nikdy nedefinovala, ze dany proces ma prezit odlogovanie z GUI session. Ona definovala, ze ma prezit stratu terminalu, co nadalej funguje, ked zavries v GUI session terminal, proces ti bezi dalej. Ono to bude tym, ze ked sa SIGHUP definoval, tak GUI sessions ani neexistovali.
Historickym vyvojom preslo, ze prve window managery nejako user session neriesili. Az prisiel consolekit/logind a riesit sa to zacalo. Pre tmux/screen/et al urobili API, aby mohli spustat svoje procesy v samostatnom scope. To, ze to upstream tmux nechce pouzivat z tvrdohlavosti, je len ich problem.
Ona definovala, ze ma prezit stratu terminalu, co nadalej funguje
Nefunguje a vůbec nevím, proč do tohoto problému taháš GUI. To, že systemd s defaultním KillUserProcesses=yes zabije všechny uživatelské procesy po odhlášení platí i pro ssh a dokonce někdo nedávno řešil případ, kdy mu systemd zabil procesy, které spouštěl z cronu.
Tedy tato změna postihla zejména serverové nasazení a žádné GUI s tím nemá nic společného.
Takže rozhodně nestačí "opravit" tmux, tahle změna toho rozbila daleko víc.
To, ze to upstream tmux nechce pouzivat z tvrdohlavosti, je len ich problem.
Ano, systemd rozbil něco, co roky fungovalo ale opravit to mají všichni ostatní. Klasický přístup.
(Bez ohledu na to, že všude používám KillUserProcesses=yes a věci se snažím řešit přes prostředky systemd, jako user services apod. Nařizovat to direktivně všem a potom ještě ukazovat na projekty, které tady byly dávno před systemd, není správné.)
ja 14.9. 11:54 [...] nikdy nedefinovala, ze dany proces ma prezit odlogovanie z GUI session. [...]
priklad. uzivatel "ja" je prihlasen lokalne na plochu, uzivatel "ja" se prihlasi vzdalene pres SSH a pusti s tmux, po nejake dobe (z jakehokoliv duvodu) restartuje lightdm s prihlasenou plochou z ktere se zadny tmux nepoustel...
- "pred systemd" - tmux na ssh bezel dal
- "pri systemd" - tmux na ssh je (ve vychozim chovani/nastaveni) zabit
podobne treba mount a /etc/fstab... mas tam definovan datovy disk, kterej (za jakehokoliv duvodu) neni dostupny, das pres ssh vzdalene reboot
- "pred systemd" - system nabehl, datovy disk nepripojen, mohl si s tim neco delat/ignorovat, nebo smazat zaznam z fstab
- "pri systemd" - system prerusi startovani, hodi te do maintenance PRED startem SSH demona, takze se na to vzdalene nedostanes, a to presto ze datovy disk NEni potrebny pro start systemu
=> musis pridat do fstab volbu nofail, coz bylo predtim default
Priklad 1 (tmux, lightdm): Pouzival ma rozbity system, bud to urobil sam, alebo jeho distribucia. By default (=ked nikto nic aktivne nepos**e) ssh sessny su vzdy samostatne sedenia, v samostatnych cgroupach.
Priklad 2: nie som si isty, ci bol predtym nofail default, ale ak ano, tak je to dost problem. Ak sa ti nenamontuje disk, ktory je potrebny pre beh systemu, tak to je dost pruser (ja mam napr. kopec veci v /srv a keby nenabehol, tak ani servisy co s nim pracuju nemaju ako). Ked admin explicitne uvedie nofail, tak potvdrzuje, ze nie je pre beh systemu nutny.
Presne do tohohle stavu se soubehem se teoreticky dostanes i s prediktivnimi nazvy sitovych rozhrani. Jednoduse proto, ze to neprovadi kernel pri inicializaci ovladace (to se vsechna rozhrani vytvori postaru - tedy jako ethX), ale provadi se az v ramci initu formou obligatniho prejmenovani... jak uz jsem zminil, sam jsem se dostal (na systemu, kde prediktivni jmena byla zapnuta) do stavu, kdy po dlouhem cekani bylo v systemu par sitovek "renameX"...
Proste je to zase jen bastl nekde za kernelem - jen pojaty trosku jinak. Systemove reseni by bylo toto pojmenovani mit uz na urovni kernelu - ale to se bohuzel nedeje.