Protože ten krám ani x let po nasazení do všech možných dister nefunguje. Teda, samotný init systém celkem ano, proti tomu bych fakt nic neměl, ale poslední dobou mi pije krev journald, který kromě toho, že když mi něco nenajede, tak hledám chybu v podivně formátovaném výstupu podivného příkazu, tak mi začal po distupgradu debianu na poslední stable na dosti serverech vyžírat místo na disku (které se dá uklízet nějakým dalším cizím magickým příkazem a i tak ty binární sajrajty zabírají více místa, než všechny ostatní logy dohromady).
Ten krám samozrejme funguje, len k tomu treba mať konštruktívny prístup a nie nadávať, že je to niečo iné ako som si v deväťdesiatych rokoch zvykol.
Keď mi "niečo nenajede", tak journalctl vie krásne filtrovať podľa jednotlivých unitov, a aj podľa jednotlivých bootov, takže viem mať samostatne logy pre servis z predošlého bootu a tohto.
Manažovať miesto pre logy vie tiež, treba sa pozrieť do /etc/systemd/journald.conf
, SystemMaxUse
(default je min(10% filesystému, 4G)) a SystemKeepFree
(default je min(15% filesystému, 4G)).
Na druhou stranu, treba debian je ted nastaven jako kockopes. S persistentnim journald jsou nektere logy duplikovane/triplikovane, zmena logovani jedne aplikace ze dedikovaneho logu do journald nam malem odpalily produkcni db servery, no, jsem zvedav, az bude postgresql logovat pres journald, jak to vyresi - ne kazdy ma /var oddelen od /.
Mně nevadí mít konstruktivní přístup k něčemu, co proti tomu devadesátkovému řešení má nějaké vylepšení, což zrovna v případě journald mi bohužel přijde, že tak není (jakkoliv třeba ten samotný init systém mi nevadí a ta unita mi přijde daleko čitelnější, než sysv scripty). Filtr dle unit a bootu zní sice fajn, ale reálně mi na textových logách ze syslogu stačil grep a časová značka a filtrovalo to to, co jsem chtěl. A měl jsem tam všechno. Teď mám kus v journald, kus stejně v normálnim syslogu, na každé používám separátní nástroje a co hůře, jelikož ty problémy, na které musím koukat do journald, nenastávají tak často, tak si samozřejmě nepamatuju jak to filtrovat (oproti grepu, na který člověk nezapomene). Takže než člověk z dokumentace zjistí co s tím, aby to pak zase zapomněl...
A tak tradicni syslog clovek nemusi pouzivat vubec, kdyz po nem "ze zvyku" skutecne netouzi. Navic syslog dost casto (v defaultu) loguje duplicitne do vice souboru - takze kdyz se neco skutecne zblazni, nakyne mu log zcela nerizene... situace, kdy zapraskal syslog cely filesystem jsou pomerne casty jev - zatimco velikost toho jurnalu jde systemove omezit... a vzniku podobnych situaci jde predejit.