Dotaz: /var/log/jurnal a velikost adresáře 1.3GB -Co je to za zhovadilost??

[frufru]

Co to je za blbost? Dnes jsem koukal na analyzátor disků a u /var/log/jurnal/nejakýnesmyslnýnázev/ polno souborů o celkove velikosti 1.3GB Zatím jsem zjistil, že to generuje systemd. Kde soudruzi od systemd udělali chybu? A neberu vysvětlení, že si to mám nastavit sám. Jedu linuxmint a zas tak velké prasárny s tou instalací nedělám. Vždyť chodím jen na internet a občas něco napíšu a vytisknu. To sy ten systemd zaznamenává všechno co dělám, že obsadí 1.3GB místa na SSD disku. Mohu smazat?

---

---

Odpovědi

[Filip Jirsák]

Panebože nad čím uvažuješ......

Samozřejmě že všechny logy pokud vše chodí OK jsou nepotřebné, ale jak se něco pokazí je dobré že je máš.

Prostě si můžeš nastavit co se má logovat a po jaké době to mazat na to je logrotate.

Jak je to v mintu netuším - prostě si to musíš nastavit pokud default nastavení ti nevyhovuje.

[frufru]

Sory, ale já jsem uživatel a ne linuxguru. Jsem uživatel. Mnoho let jsem bez systed existoval a světe div se, system nežral místo na disku. Linuxu přestávám rozumět a vážne uvažuji, že si koupím něco od Apple. Čím dál víc se to začíná podobat windows 10. Prosím zavřít vlákno.

[ewew]

Len podporuj produkty typu vyrobca povedal, že to tak je správne.

[Petr Fiedler]

Pokud by sis opravdu chtěl koupit něco od Apple, tak se napřed podívej na tohle.

[Filip Jirsák]

To nie je blbosť ale záznam o činnosti systému. Logy sú určené na zisťovanie stavu systému a jeho bezpečnosť. Napríklad auth.log obsahuje správy týkajúce sa bezpečnosti systému. Zaznamenáva časy prihlásenie a odhlásenia. Nie pre kontrolu tretím stranám ale samotnému užívateľovy.

Podľa dokumentácie systemd, bude vždy najstarší súbor aby bol zachovaný limit využitia disku.

Máš niekoľko možnosti. Jedna je nastaviť journal, tak aby ukladal len do RAM a nechať logovať len rsyslog. Druhá je nastaviť menší limit využitia alebo zmeniť logovanie menej dôležitých správ.

Použi príkaz journalctl -p warning a skontroluj či tam nie sú hlásene nejaké problémy. Zaplnenie logov dochádza aj v prípade zle podporovaného hw. To znamená, že určite by som pozrel log, či je to spôsobené len dĺžkou záznamu alebo je tam nejaký problém.

[Pavel 'TIGER' Růžička]

Asi takhle, chceš li vzpomínat na retro časy, pak můžeš na svůj SSD nainstalovat FreeDos a do něj vhodný emulátor. Porovnej, kolik kilobytů se vešlo na audiokazetu s dnešním 512GB, či dokonce 1TB ssd. A co vyjde levněji v poměru cena / výkon / čas? Ano programuje se jinak. Ale více, než zábor místa mne štve funkčnost a (ne) rozbitnost systému. Tady se točíme v nějak nesmyslném kolečku.

[Filip Jirsák]

If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the underlying file system but capped at 4 GiB.

Upravit to muzes hodnotou SystemMaxUse=100M v /etc/systemd/journald.conf a vymazat na hranici 500M prikazem:

journalctl --vacuum-size=500M

[Josef Kufner]

Zamyslel jste se někdo, kolik textu je 100 MB?

Po nabootování mi dmesg vypíše něco přes 1200 řádek o celkové velikosti cca 100 kB. V logu systemd (journalctl) je toho zhruba dvakrát tolik při přibližně stejně dlouhých řádkách. Tedy 100MB log bude obsahovat zhruba přes milion řádek. To je pro naprostou většinu počítačů naprosto přehnané množství, tedy vyjma specializovaných logů na serverech.

Pro běžný desktop bych nechal logování jen v paměti a omezené klidně jen na pár MB. Beztak když je s něčím problém, tak je zajímavých buď jen posledních pár řádek, nebo ta cca tisícovka při bootu. Aspoň se nebude trápit SSD neustálými zápisy.

[lertimir]

S takovouto otázkou jsem se trápil tak před 5 lety. V současnosti se znalosti, jak se opotřebovávají SSD bych to již neřešil. Jednak množstí zápisu, které log generuje je zanedbatelné z hlediska normální životnosti SSD. Mám nastavený 4GB prostor pro log, což v ceně SSD znamená, že jsem mu vyhradil prostor za cca 38 Kč. Nyní jsem se do něj podíval a mám v něm něco přes 5 milionů záznamů. první jsou ze začátku srpna a asi je to jen tak krátkou dobu, že jsem mi, jak jsem už tady se psal, rozpadalo pole a bylo do logu proto záznamů hodně. Množství zápisu se ostatně jinak nezmění rezervováním méně nebo více místa, to je jen úložný prostor. Nesouhlasím s tím, že podtatné jsou jen poslední řádky, protože zpětně mohu hledat, kde problém začal se objevovat. Mnohdy to může být po aktualizaci a pak se dá se vrátit zpětně k balíku.

[j]

Ono se hlavne normalne (tudiz nikoli v systemd, tam nic normalne nefunguje) loguje trebas tyden(na ty stanici) nebo mesic(na serveru) a vubec se neresi kolik to zabira, zalezi pak jen na tom, jak moc bordelu ti tam apky ladujou. Pripadne se jeste rekne "ok, jeden soubor 1 MB, staci bohate 5x" a normalni logger to pad odrotuje. A samo, normalni nastaveni appky je nekde na urovni error only, pripadne +warnings.

[xxl]

Když si odmyslíme tu super věc, že systemd-journal loguje do binárních souborů, které se nedají bez journalctl přečíst, tak vlastní řízení objemu logů je řešeno docela dobře. Je to uděláno obdobně, jako v daemontools. Prakticky nehrozí, že logy zaberou všechno místo na disku, protože se zavčasu mažou, když už dochází místo.

[Petr Fiedler]

Odkud tuto informaci máš?

[Josef Kufner]

Viz man journald.conf:

       SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=,
       RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=
           Enforce size limits on the journal files stored. The options prefixed with "System" apply to
           the journal files when stored on a persistent file system, more specifically /var/log/journal.
           The options prefixed with "Runtime" apply to the journal files when stored on a volatile
           in-memory file system, more specifically /run/log/journal. The former is used only when /var is
           mounted, writable, and the directory /var/log/journal exists. Otherwise, only the latter
           applies. Note that this means that during early boot and if the administrator disabled
           persistent logging, only the latter options apply, while the former apply if persistent logging
           is enabled and the system is fully booted up.  journalctl and systemd-journald ignore all files
           with names not ending with ".journal" or ".journal~", so only such files, located in the
           appropriate directories, are taken into account when calculating current disk usage.

           SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most.
           SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave
           free for other uses.  systemd-journald will respect both limits and use the smaller of the two
           values.

           The first pair defaults to 10% and the second to 15% of the size of the respective file system,
           but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or
           RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the
           percentage that is actually free. This means that if there was enough free space before and
           journal files were created, and subsequently something else causes the file system to fill up,
           journald will stop using more space, but it will not be removing existing files to reduce the
           footprint again, either. Also note that only archived files are deleted to reduce the space
           occupied by journal files. This means that, in effect, there might still be more space used
           than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.

           SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow
           at most. This influences the granularity in which disk space is made available through
           rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with
           SystemMaxUse= and RuntimeMaxUse=, so that usually seven rotated journal files are kept as
           history.

           Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to
           1024, 1024², ... bytes). Note that size limits are enforced synchronously when journal files
           are extended, and no explicit rotation step triggered by time is needed.

           SystemMaxFiles= and RuntimeMaxFiles= control how many individual journal files to keep at most.
           Note that only archived files are deleted to reduce the number of files until this limit is
           reached; active files will stay around. This means that, in effect, there might still be more
           journal files around in total than this limit after a vacuuming operation is complete. This
           setting defaults to 100.

[Petr Fiedler]

Dík

Takže oddělovat /var, aby se nezaplnil / logy a systém nenaběhl v tomto světle postrádá smysl, že jo?

[Petr Šobáň]

Prakticky ano.

Samozřejmě vždy může někde nastat chyba a systém nenaběhne.

Kdysi jsem HDD taky dělil dnes už to nedělám, na domácím PC to nemá smysl i když vlastně tam jsem to zase začal dělit ale spíš stylem celý OS na velmi rychlém ssd a data uživatelů zase na velkém plotnovém HDD.

Samozřejmě u velkých serverů kde se mění HDD/SSD za provozu je to zase o něčem jiném.

[Petr Fiedler]

Díky Petře.

[Filip Jirsák]

Nastav si to v souboru /etc/systemd/journald.conf.

[Petr Fiedler]

Nějak nechápu, s čím máš problém. Tak má nějaký adresář velikost 1,3 GB. A co jako? Děláš, jako kdybyste vyhořeli.

[rastos]

Ľudia, čo používali DoubleSpace nezvyknú mávnuť rukou na gigabajtom dát. Škoda, že dnešná generácia je v tomto iná.

[Petr Fiedler]

Tak mě je 41 let, takže asi nespadám do toho, co jsi myslel tím "dnešní generace". Navíc si myslím, že co se kapacity datových úložišť týče, tak jiná byla situace v roce 1993 viz. článek co jsi odkázal a jiná je dnes. A taky ceny jsou jinde, že? Takže bych to zase tak dramaticky neviděl.

[frufru]

Když člověk začínal na Atari 800, 286/386sx/486dx2/celeron300a/pentium a úložiště byla kazetová páska, 5 1⁄4 disketa, ​3 1⁄2 disketa, 20MB/40MB/160MB/500MB disk, tak si váží místa na SVEM disku. NAprosto nechápu, že si nějaký program dovolí obsazovat místo na mém disku. I když je to OS. Tohle je chorobný přístup dnešních programátorů. Místa je dost, tak proč to řešit. Nikoho z těch "programátorů" ani nenapadne, že to může běžet na embendded/raspberry pí počítači, který má malou paměť. Linuxu dlouhá léta stačilo 5GB místa na disku. Proč teď stále bobtná a už po roce od instalace mám obsazeno 26GB ze 30GB, které jsem mu vyhradil. Windows 10 home má 40GB. Opravdu se mi nelíbí, kam to všechno směřuje.

[Petr Fiedler]

Jenomže doby Atari 800 XE, Commodore Amiga 500, nebo 486 DX2 už jsou v nenávratnu. HW nároky rostou i s ohledem na SW. Těžko (pomineme kompatibilitu) bys narval Windows 10 do Amigy 500. Vše se posouvá. To bys s takovou taky mohl chtít používat diskety a nadávat, proč se na ně dnešní sw nevejde. Ta doba je prostě pryč. Jsem rád, že jsem jí zažíl, ale chápu, že je pryč a přizpůsobuji se tomu. Když potřebuji místo, tak se je můžu za pár peněz pořídit. A lze to tak řešit i u tebou zmiňovaného RPi. A pořád je možnost, když člověk z nějakého důvodu nemůže/nechce zaplatit, nakonfigurovat to. Rozhodně mě to ale nechává klidným a nebudu kvůli tomu histerický. Nic ve zlém :)

[k3dAR]

zacinal sem na Commodore64, Amiga500, kdyz sem pak k Amiga1200 pripojil 2GB HDD tak sem mel pocit ze se tam vejde "cely" "svet", ale jak pise Petr je to nemozne srovnavat s dneskem, resp. ne zpusobem kterym to chces srovnavat, jasne ze se u spousty programy prasi do Elektronu, spousta je jich v Pythonu, nikdo uz neprogramuje v Asembleru aby vytahl ze stroje maximum, ale to bych sem netahal, to ze 1.3GB zaberou logy je o tom ze se to loguje pro pripadnou diagnostiku, ja nemel problem udelat 16GB swap na 128GB SSD kdyz chtel hibernovat na disk, ani nemel problem misto 128GB SSD dat 512GB SSD (resp. dnes kdyz vidim ceny tak bych dal 1TB SSD), pokud ale nekdo ma 32GB SSD tak ma moznost si velikost tech logu nastavit na mensi nebo je treba i vypnout(na svoji zodpovednost)...

jestli ti instalace GNU/Linuxu z 5GB nabobtnala na 26GB, muze to byt jen tvoje nepozornost, koukal si co ti misto zabralo? nejde o stare jadra ktere tve distro zapomina mazat? nejde o nejake nepotrebne cache? tebou doinstalovavane hry? atd... co treba se podivat:

sudo ncdu -x /

[Petr Fiedler]

BTW: hrál jsi na Commodore 64 hru Robin Hood? To byla paráda :) Jó, dětství bylo super.
Nedávno buď tady, nebo na rootu vyšel článek, že někdo přidal několik set DOSových her na nějaký web. Tak jsem si (na Linuxu) s nostalgií zahrál Prince of Persia a zatlačil slzu

[k3dAR]

Robin Hood si nevybavuju, co si vzpominam hral sem na C64 Giana Sisters, InternationalKarate, BoulderDash, StuntCarRacer, Green Berret, na Amize pak SuperFrog, Turrican*, Lotus*, Dynablaster (ve 4 s 4port joy adapter) a hromadu dalsich co si ted nevzpomenu ...
ten web byl nejspis Archive.org

[Petr Fiedler]

Na Amize 500 Plus: zrovna koukám na YT na Shaddow of the Beast II, Prehistorik, Chuck Rock, Super Hang-On, Lotus Turba Challenge 2 - hudba byla super, Myth, Prince of Persia, Adams Family, Super Street Fighter 2 Turbo, Superfrog, SWIV, GODS a spousta dalších...

[k3dAR]

tak "Shadow of the Beast", ChuckRock, SWIV, Myth taky Lotus ve 2lidech na 2 Amigach spojenych pres serial kabel a pak nevim jak sem mohl nevzpomenout perly jako Project-X, AlienBreed*, GoldexAxe, Moonstone, AnotherWorld, Flashback, TestDrive, Apidya

[k3dAR]

EDIT: odkaz u AnotherWorld byl omylem na Non-Amiga verzi => AnotherWorld (Amiga)

[Petr Fiedler]

Another World? Totální mazec! Taky nechápu, jak jsem to mohl opomenout?

[Petr Fiedler]

A tohle?

[k3dAR]

matne, takze asi jo a pripomelo mi to Rick Dangerous a pridam jeste Agony, Buba'n'Stick, Cannon Fodder, Wings of Fury, LionKing, UGH!, Pushover, Lemmings, Walker, Lionheart, NoSecondPrize...

[Petr Fiedler]

Lemmings byli skvělí. A ještě bojové šachy. A napadá mě ještě pár skvělých her, ale na názvy už si nevzpomenu. To byly časy.

[Petr Fiedler]

Když na to koukám, musím se smát Pochopitelně, tenkrát to byla raketa, ale dnes je to opravdu úsměvné

[lertimir]

No pro mne první setkání s počítačem po programovatelné kalkulačce, byla děrovací místnost a krabice od bot s štítky s FORTRANem a nebo PL1, tam člověk jednat šetřil každý řádek a jednak nesměl s krabicí zakopnout. Ale o to je teď jedno. Jednak systém obsazuje tolik místa, kolik mu nařídíš. To "bobtnání" systému typicky je záležitost tří struktur. Jednak logy (v menší míře), za druhé aktualizace (protože obvyklá strategie v současnosti bývá nechat starší balíky v archivu systému proto, aby se uživatel mohl vrátit pokud potřebuje. Opět lze nastavit.) a třetí zdroj bobtnání jsou na btrfs filesystémech snapshoty (a opět lze nastavit detailně strategie, co s tím). Všechno to jsou smysluplné a žádoucí postupy. A je jen na správci systému, jakou roli a jaké prostory jim nastaví.

A to jak o příspěvek výše píšeš, že jsi jen uživatel. To je jak bych slyšel od někoho, že je jen řidič. No může být, ale celkem bych doporučoval, aby pak měl někoho kdo mu vymění olej, zkontroluje čas od času brzdovou a chladící kapalinu, prohodí gumy mezi zimními a letními, a provede další potřebné diagnostiky a úkony. Znám dámu, která o kámen prorazila vanu a jela pak tak dlouho až zadřela motor, a když jsme se jí pak ptali, proč nezastavila, tak říkala, že sice "tam" něco svítilo, ale nemyslela, že to je důležité. Tož tak.

[Petr Fiedler]

A to jak o příspěvek výše píšeš, že jsi jen uživatel. To je jak bych slyšel od někoho, že je jen řidič. No může být, ale celkem bych doporučoval, aby pak měl někoho kdo mu vymění olej, zkontroluje čas od času brzdovou a chladící kapalinu, prohodí gumy mezi zimními a letními, a provede další potřebné diagnostiky a úkony. Znám dámu, která o kámen prorazila vanu a jela pak tak dlouho až zadřela motor, a když jsme se jí pak ptali, proč nezastavila, tak říkala, že sice "tam" něco svítilo, ale nemyslela, že to je důležité. Tož tak.

To jsi vystihl.

[noob]

Skoda ze stale textove aplikace maji takove problemy otevrit takove soubory a to i obycejny text a to i pokud je v systemu 16GB RAM. Problem je v tech aplikacich a to jak treba v GVIMU tak treba gnome-logs. Ma zkusenost je takova, ze je jedno jestli mate 10 let stary stroj nebo zcela novy mnohem vykonejsi.

[rastos]

Iste je dostupná vyššia kapacita, za menej peňazí. Takže?! Hrr, poďme s ňou plytvať! Tak si to myslel?

Dobre, nie je to dramatické a nebude to príčinou mojich bezsenných nocí. Len hovorím, že by sme nemali podporovať bezhlavé plytvanie. Nebudem naháňať každý bajt, ale ani nemávnem rukou na gigabajtom, ktorý mi nepriniesol výrazne viac funkcionality.

[k3dAR]

tak nemavej a velikost logu si zmensi podle svejch preferenci ne?

[rastos]

Iste. Tým smerom leží aj rada "veď si to naprogramuj sám".

[Petr Fiedler]

Rastosi, ať se ti to líbí, nebo ne, tak Linux vyžaduje znalosti. Není pro lidi, co nechtějí proniknout hlouběji. Pro ty jsou Windows. Těm je většinou ale úplně jedno, kolik místa na disku zabírá složka s logy. Patrně o ní většinou ani neví. A nastavit si limit pro logy přece není až takový problém. Něco naprogramovat je rozhodně těžší. k3dAR ti to napsal dobře.

[Michal]

Nejhorsi je, ze ta svine svinuta je schopna si tohle za urtcitych okolnosti udelat i v tmpfs.

/run/log/journal# du -hs *
928M    53e9e2d5305041ae9a3af2563fd56d45

Dalo by se mozna argumentovat, ze diskova kapacita je levna a smi se ji plytvat. Budiz. Ale o plytvani RAM mi to uz nikdo nenakeca. A take mi nikdo nenakeca, ze ty defaultni hodnoty limitu nevymyslel _idiot_.

Ja si msylim, ze si systemf v tom binarnim blobu, ve kterem se nikdo nevyzna, pomalu vyuiji skynet. Lidstvo by mela vyslat terminatora zpet casem na Lennarta

[Peter Golis]

Systemd má nastavený limit na tmpfs do veľkosti 10% RAM, a to je vždy menej ako vyžerie ľubovoľný prehliadač internetu pomocou JS.

Rád by som si vypočul fundovaný názor že prečo Firefox/Chrome alebo Chromium môžu zožrať celú RAM (aj keď ju nepotrebujú a ani nevyužijú) a Lennart nie.

[Michal]

1) Prohlizec nesmi zrat RAM k snidani. Pokud to dela, nadavam na neho take (mozna to bude tim, ze pocitac, na kterem jsem poprve brouzdal mel 57x mene RAM nez ma tenhle Lennartuv log tak jsem na to citlivy

2) Prohlizec je apka, kterou aktivne provozuju na popredi a jsem tedy smiren, ze zere zdroje. Od pomocne sluzby na pozadi ocekavam, ze bude zrat zdroju minimum. Kde jsou doby, kdy se rikalo, ze Linux nechava vic prostredku aplikacim protoze jich potrebuje mene na vlastni beh? Protoze to zjevne uz neplati nebo to minimalne neni priorita.

3) Kolik je pripadu, kdy 900MB zurnal pomohl prumernemu uzivateli k reseni nejakeho problemu ale 8MB by nepomohl? Odhlizeje od toho, ze pokud Linux aspiruje na pozici desktopoveho OS, tak majorita uzivatelu nesmi vedet, ze tam neco takoveho vubec je natoz aby studovali co v tom je.

4) Tohle je server a prohlizec tam nebezi takze to tvoje srovnani je vlastne zcela mimo a nevim, proc se nim tady zabyvam.

[Peter Golis]

A to je nejaký moc veľký problém zmenšiť východzie hodnoty na absolútne minimum, a doinštalovať si tradičný syslog?

PS: U mňa nebeží prehliadač väčšinu času na popredí, ale aj napriek tomu RAM vo východzom nastavení neuvoľňuje ani keď ju prestane používať.

[xxl]

Ono je taky možné nechat /etc/systemd/journald.conf na defautních hodnotách (všechno zakomentovat) a prostě smazat adresář /var/log/journal. Pak se loguje jenom do paměti (do které se loguje stejně vždycky) a na disk se nic neukládá.

[Michal]

Ale to tady celou dobu resime Mlho, ze mi log zabira skoro 1 GB RAM (a nikoliv mista na disku) a ze to neni prilis efektiivni vyuziti RAM...

[xxl]

Blbečku, tak si to nastuduj a vyzkoušej.

[Michal]

Co mam studovat a zkouset? Ja to v pameti mam. Hned v prvnim prispevku toho vlakna jasne pisu, ze se jedna o /run/log a tedy tmpfs. A kdyz to mam tam, tak to logicky nemam ve /var/log. Kdyz nerozumis psanemu textu, tak jeste kvuli tomu neni nutne lidem nadavat.

[xxl]

Myslel jsem, že nadávky jsou ti vlastní.

Jestli tomu rozumíš, tak si to nastav, jak potřebuješ a je to.

Když nechci nic řešit, tj. mám dost paměti a místa na disku, tak to prostě neřeším a nechám to na defaultních hodnotách. A když se mi při instalaci nevytvoří journal na disku, tak ho vytvořím. Když s tím provádím vylomeniny a mám něčeho málo, tak si na log vzpomenu a zamyslím se, kolik a jak dlouho ho potřebuji a podle toho ho nastavím.

[Michal]

Podle ceho jsi tak usoudil? Ja vynadal jen systemd (a to jeste velmi velmi slusne a jemnocitne... kdyz to srovnam s tim, co casto slysim od nasich adminu a opsu). Zadnemu cloveku jsem nevynadal.

Takovy pristup, jaky popisujes, by sel aplikovat kdybych bral OS jako nejakou bojovou hru. Ha, problem! Hura uz se tesim az nastuduju, cim to je a jak to opravit. V takovem pripade jsou umele nastrazene problemy vyhodou. Jenze ne kazdy ma takovy pristup a soucasne cas takhle postupovat. Nebo ani nevi, ze ma PC pribrzdeny protoze 1GB RAM je pouzity na log misto na diskovou cache. Proto by melo defaultni nastaveni davat smysl.

[xxl]

Debian, 2 GB paměti, journal jen v /run/log/journal, /run je tmpfs o velikosti 10% paměti (default). Max velikost logu si systém spočte podle velikosti /run. RuntimeMaxUse=15% (default). Velikost logu je max 30 MB, granulace po 1/8 z těch 30 MB. 30 MB přežiju.

[j]

Tak to je jasny ze negramotnej picus jako ses ty nemuze pochopit, ze podobny vychozi hodnoty muze nastavovat leda nebramotnej picus, jako ses ty ....

Vis ty hovadko, ze na tom stroji taky takovych systemu, kde si prece kazdej veme ten "par set" MB muze bezet taky par desitek? 30MB nemaj ani vsechny moje logy dohromady ... protoze hromadeni logu, zjevne narozdil od picusu, neni moje hoby.

[lertimir]

No to jestli systemd-journald píše do /var nebo to /run je mu srdečně jedno. Určitě nezjištuje jaký ty FS na místě je. Podle dokumentace jsi se v zásadě rozhodl, že to chceě mít v /run ať již parametrem v journald.conf nebo nedostupností /var/log/journal. Nerozumím tomu, proč bych měl chtít mít log v RAM, protože pro mě je log primárně potřeba, když zjištuji, zdali se věci dějí a děly, jak mají a to mi RAM neposkytuje dostatečně. A samozřejmě cena úložného prostoru je jednak jiná a také log je ta poslední datová struktura, která by potřebovala rychlý přístup.

[Michal]

Neni. Na druhou stranu vychozi hodnoty by mely byt sane. Nyni jsou insane Nebo tak, ze BFU (ktery by s logem pokud mozno nemel vubec prijit do styku) by to mel mit nastavene spravne. A kdo tomu rozumi a vi, ze potrebuje vetsi zurnal, tak si to nastavi.

[Peter Golis]

Východzie hodnoty pre objem logovania sú nastavené tak, aby v nich človek vedel nájsť príčinu problému. Či už sám, alebo cez automatické reportovania problému ktoré nájde problém s podobnými symptómami (a dosť často aj s riešením).

Ale o tom je zbytočné sa hádať. Ak človeku vadí že jeden program neuvoľňuje pamäť aj keď ju nevyužíva a druhý program využíva oveľa menej pamäte, tak je to unikátny prístup.

[Michal]

Pokud by to bylo tak, jak pises, tak by velikost logu mela byt nezavisla od velikosti pameti/disku ne? Pro reseni problemu na PC s 32GB pameti preci nepotrebujes vetsi kus logu nez na PC s 2GB.

Tu druhou vetu nejak nechapu. Kazdopadne jsem nekde vyse napsal, ze mi vadi _kazde_ plytvani pameti.

[Peter Golis]

Áno, tak to je. Veľkosť systemd žurnálového logu je niekoľko percent zo storrage (disk/RAM), s presne definovanou maximálnou hodnotou. Tá maximálna hodnota je nezávislá od celkovo dostupnej veľkosti daného typu storrage. To tu už bolo X krát povedané rôznymi ľuďmi.

A k tomu tvojmu druhému odstavcu, ja zas nechápem prečo ti vadí plytvanie u jedného programu ktorý tú pamäť nevyužíva (prehliadač internetu po vypnutí TABu tú pamäť ozaj neuvoľní). Ale u iného programu ti to vadí (ak tú pamäť reálne aj používa).

To naozaj takto chabo trolíš?

[j]

Muzu se zeptat co beres? To musi bejt slusnej matros. Chci totiz videt jak naprosto cokoli hledas v GB logu.

[Peter Golis]

Obvykle na to staci stlacit lomitko, a zadat vyhladavaciu frazu.

[GeorgeWH]

... a cakat par dni, kym to zbehne, ze? Uz by si mohol prestat vnucovat ostatnym tvoju "pravdu".

[dustin]

Nevím, co používáš, ale less prohledává txt GB soubory zcela bez problémů. Ovšem nevím, jak je to v případě těch binárních mrch, naštěstí jsem ještě neměl to potěšení.

[GeorgeWH]

Par-krat som potreboval prezriet par GB txt log. Uz len nacitanie trvalo nejaku dobu a o samotnom vyhladavani ani nehovorim. Jasne, nie je to az take hrozne, ale tie lagy mi lezu na nervy. Dalsi problem je, ze sa v takom subore velmi zle pohybuje. Vacsinou potrebujem pozriet logy z nejakeho obdobia a pohybovat sa vo velkom logu je problem. Pri rozdelenych logoch si grep-om zistim, kde sa nachadza hladany retaz a potom hladam uz len v malych suboroch.

[Petr Fiedler]

A ty malé soubory zabírají dohromady stejně místa, jako původní velké, že jo?

[GeorgeWH]

Neviem, co tym myslis, ja som hovoril o jednom konkretnom pripade (zabudnute rotovanie openvpn logu). A ano, tie male subory (logy) zaberaju menej miesta, ako keby boli v jednom subore, pretoze su komprimovane.

[KOLEGA]

Muzes taky hledat po unitach, datu a tak dal. Diky tomu, ze to je binarni log, tak je to podstatne rychlejsi, nez grepovani, nebo prave ten less.

[k3dAR]

[...]mozna to bude tim, ze pocitac, na kterem jsem poprve brouzdal mel 57x mene RAM nez ma tenhle Lennartuv log tak jsem na to citlivy [...]

to tim nebude, ja poprve brouzdal s 666x mene RAM a pupinky jako ty nemam...

[dustin]

1,3GB/666 je méně než 2MB. Roky jsem měl 486SX25 notebook se 4MB RAM (později upgradované na 8MB přídavnou kartou), Mozaika na něm běžela, stránky se tehdy přes modem načítaly, ale že bych to mohl dávat do nějakého srovnání s dnešním webem, to opravdu nemohu...

[k3dAR]

ano, Amiga A1200, 2MB RAM, mk68020@14MHz... ja to nesrovnaval s dnesnim webem, viz citace

[rastos]

S tým tvrdením by som sa tak moc neponáhľal Mnoho ľudí na dnešný web lezie s NoScript-om. Takže vlastne oproti tomu Mosaic-u potrebujú ešte čo? Ešte niečo okrem CSS? (A vyhodili podporu pre gopher )

[j]

Protoze tu appku chce uzivatel pouzivat, ale nejaky posraty tempy je naprosto nezajimaj?

Jinak tyhle blaboly lidi ktery netusej co zvanej me fakt dojimaj ... mam tu hosicku stroje co maj stovku jader, stovky GB ram a desitky TB diskovy kapacity ... vis co neustale chybi? Ramka. Pristi cyklus obmeny HW bude s tim, ze ramka pude pres TB. A vis proc? Protoze to pisou presne takovy negramotny bridilove, jako ses TY.

[Peter Golis]

Tak v tom pripade places na nespravnom hrobe. Skus zalogovat ticket spravcom tvojej oblubenej distribucie ze by si si rad zaplatil fork instalacneho media ktore ma pre desktop vypnute kompletne cele logovanie.

[debian+]

Asi mas zapnute jurnalovania ukladat na disk. Ja instalujem Debian mininal + co chcem nasledne a /run/log/journal a /var/log/journal take priecinky ani nemam.

Ak sa ti nechce nastavovat system, tak to nerob. A daj to niekomu inemu.

Ak mas maly odiel, tak sa da zvecsit (zoberie si z ineho odielu).

Archivovanie je blbost, pokym neprides o data. Gitovanie kodu je blbost, pokial sa nepotrebujes vratit v historie kodu naspat.

[Petr Fiedler]

Pro tmpfs jsem naalokoval 4 GB RAM a problém nemám. A kdybych měl, tak přidám klidně další 4 GB. O co jde?

[Petr Fiedler]

BTW: když se tady tak vzpomínalo na dřívější časy, tak já pamatuji doby (cirka před 25 lety), kdy 1 MB RAM stál 1k Kč. Takže dnes je to zase někde úplně jinde.

[debian+]

tmpfs je suborovy system v pamete RAM. Najviac sa pouzivuje kolko je pri pripojeni definovane, inac v realne zabera kolko su v tom subore.

Pouiva sa, ak data nechceme ukladat na disk/medium (kvoli setreniu opotrebovaniu disku) alebo najme kvoli rychlost (RAM je rychlejsia na RW operacie ako disk).

Napriklad robim v RAM zmeny vo ramfs: Nacitam obrazok z disk -> preskalujem -> konvertnem do CB -> pridam otlacok -> a az nasledne ulozim na disk. (Da sa aj jednym prikazom, ale co ak chcem postupne).

[Petr Fiedler]

Já vím co je tmpfs, jak funguje a k čemu slouží.

[kolemjdouci]

Nerozumis tomu ale utocis, jsem zvedavy jestli by jsi mel argumenty kdyby jsi mu stal naproti. Jsi hloupak, prosty cech.

[Michal]

Rekl bych, ze docela rozumim... Ale na pochopeni toho, ze zabrat GB RAM na nejaky log je zhovadilost myslim staci selsky rozum. Ano, mel bych stejne argumenty. Nejsem Cech (patri tam mimochodem velke pismeno), cestina neni muj matersky jazyk. Kdybych byl Cech, tak bych mel ceskou klavesnici a nepsal bych bez nebodenicek jako hotentot

[Petr Fiedler]

Jen pro tvou informaci. Nejsou to nebodeníčka, ale nabodeníčka.

[frufru]

Vyvstává pár otázek. 1) Můžu za to já, protože jsem jen uživatel linuxu a ihned po nainstalování nějaké(linuxmint)distribuce okamžitě neprolezu všechna nastavení konkrétní distribuce? 2)Udělali chybu správci distribuce, protože nedali omezení na velikost log souborů. 3) Udělali chybu programátoři konkrétní aplikace, protože tam nedali nejakou pojistku v podobě automatického odmazánístarších logů.

Buď jsem profík a tak vím, že na server nainstaluji jen co tam má být, nebo jsem uživatel a pak mi zajímá, jestli je z bezpečnostního hlediska OS aktuální. Vždyť se to neobjeví ani v oznámení, abych mohl zareagovat. Kdo je guru ten ví kde hledat a ostatním radši nic neukázat. Vlastně proč plašit tu uživatelskou menšinu nějakým oznámením. System se aktualizuje, při startu nic červeně nehlásí, startuje přiměřeně rychle tak sakra proč bych se měl pídit po nějakém nastavení logů? Ve WIN to taky nehledám a nenastavuji a v OS Mac to snad taky uživatel nedělá. Tak kde je chyba?

[Michal]

Kdyz budou uzivatele nam vyvojarum prezentovat takovy postoj, tak se podle toho pak ale zachovame. Proc psat nativni apku, kdyz to bude snazsi v electronu? Bude zrat nekolikrat vic pameti a bude pomalejsi? Rikali, ze to nevadi. Proc balickovat soft separatne pro kazde distro, kdyz ho muzeme vrznout do snapu a je to? Ze se to spousti o dost pomaleji? Neva, rikali, ze jim to nevadi. Proda se vic procesoru a pameti. To Gretku nepotesi ale co. Kdyz dene pouziva PC 3 mld. lidi a kazdy z nich prijde v souctu o minutu kvuli ruznym neefektivitam tak to je jen 5700 promarnenych clovekoroku. Cert s tim, rikali, ze to neva

[ewew]

Môžeš sem dať obsah /etc/crontab ?

[GeorgeWH]

Odbornik prisiel...

[theseuszn]

Jen tazateli podávám moje info: můj CELÝ "var" má 4GB, CELÝ "log" uvnitř má 163,2 MB!!!, jedinej "lib" má 3,8 GB z mnou uvedeného obsahu CELÉ SLOŽKY "var" při 4 GB celkem. Tak je dost podivné, co uvádíš v dotazu ohledně složky: "/nejakýnesmyslnýnázev" a její velikosti 1,3 GB. Pokud používáš systém jak uvádíš, tak taková složka ala "nesmyslnýnázev" ti tam NEMŮŽE vzniknout. Proto mi z tvého původního dotazu vyplývá toto: buď lžeš, nebo neumíš číst hodnoty. Na nic se neptám, nic ti neporadím, při tvé forrmulaci dotazu to asi ani dost dobře nepůjde, pokud vůbec. Normálně a bez jakýchkoliv úprav používám ke své plné spokojenosti LM 19.2, x64 Cinnamon.

[theseuszn]

Příloha:

• analyzátor využití disků v LM 19.2.png (119827 bytů)

Opoměl jsem přiložit zobrazení Analyzátoru využití disků v mém LM

[frufru]

adresář var má 6.3GB. adresář /var/log/journal/4095cb9d62054733b651d895c996ea84/ teď obsahuje 99 souborů od velikosti 8.4MB,16.8MB, 25.2MB, 33.6MB, 41.9MB, 58.7MB o celkové 1.2GB a to vždy v několika exemlářích. Jen ty poslední dva jsou po jednom. A nesmyslná jména souborů vypadají asi takhlesystem@1cee8861faf9462dbe0688bebbfdc434-000000000000ec2e-0005870fe1f582f7.journal

Pánové nastavit si to umím, ALE myslím, že základním nastavení (default) by tohle povolit neměl. Proč se základní nastavení to do nedávné doby dodržovalo? Pokud jsme chtěli něco změnit v jakémkoli nastavení, tak to bylo na naše riziko a udělal jsem si to po svém. Mám server, tak dám logovat klidně měsíc. Mám OS jen na normální věci, tak loguji den, týden, ale ne celý rok, když není nějaký problem. Může se člověk spolehnout na system, kde vývojáři přestali tohle dodržovat? V základu se má system chovat korektně a neutrálně. Nemá rozhodovat za mne, že potřebuje plno paměti, disku a spoustu jiných prostředků. Proč se tento narcismus programátorů a sestavovatelů distribucí projevuje v OS. Když někdo na takové zhovadilosti ukáže, tak z oznamovatele děláte neschopné si nic nastavit, za každou větou je cítit zlost až nenávist. Pak to většinou skončí tím, že si máme vybrat jinou distribuci, nebo se vrátit k WIN. Je mi z toho smutno.

[k3dAR]

vidis to jen ze sveho pohledu, kdyby byl limit na 1.4MB abys mel radost ze se vejde na 1x 3.5" disketu, tak by se ozvali jini ze v Logu nenasli co potrebovali protoze byl ve vychozim stavu nesmyslne malej kdyz maji 1TB SSD/10TB HDD atd...

btw: nicmene, pokud ti nekdo neveri kolik zabira tve journal logy:

journalctl --disk-usage

[lertimir]

Promiň, ale takhle to není. Základní nastavení se dodržuje. Jenom je jiné, než základní nastavení, které bylo před 20 lety. Zavedení systemd změnilo mnohé, ale pokud se s tím člověk seznámí, tak v naprosté většině situací je pro mne práce se systemd lepší než byla dříve. Systemd je skutečně významná změna a pracuje se s ním jinak.

V současnosti je limitace logu journald dána velikostí a ne časem, jak starý je log. A default pravidlo je maximálně 10% filesystému, nechat minimálně 15% volno a maximálně 4GB, aplikuje se nejmenší hodnota z těchto. Což dle mne není špatné pravidlo a je jednoduché. Když ti poroste někde systém tak umaže logy a nikdy neporoste do absurdna. Pravidla se aplikují při každém zápisu, takže log nemůže narůst jako při logrotate, když se narazilo na nějakou silnou generaci chyb.

Nesmyslná jména mají asi takovou strukturu, že je tam system.journal a user-1000.journal (kde 1000 je UID uživatele) To jsou aktuální logy a pak jsou tam starší logy, které mají nagenerovanou strukturu jak píšeš.

[Petr Fiedler]

Jsem rád, že jsi to tu tak krásně vysvětlil.

[theseuszn]

Příloha:

• var-obsah.png (175103 bytů)

Zlobu žádnou k nikomu necítím, když už, tak se asi nešťastrně vyjadřuji (to je můj boj). Na tom ovšem, ať jsou výpisy jakékoliv, nic nemění to, že o serveru si v původním dotaze nic nepsal. Za další, znovu přikládám snímek z nástroje, o kterém se v původním dotazu zmiňuješ (Analyzátor využití disku), kde je to jasně vidět a nepotřeubuju tady "vynikat" s terminálem, zkrátka a dobře reaguji pouze v duchu a znění tvého původního dotazu. Pochybnosti o možnosti, že jsi možná lhal beru tedy zpět a omlouvám se, byť ty názvy souborů sou mi u zadku. Primárně ti šlo o velikost nějakého souboru ve složce: /var/log/journal/f3d85c83fd6e458aba76dbf56f683032.....  Trochu mne jen udivilo tvé rozhořčení nad věcí a způsob vyjádření, kterým si situaci popsal. Takže je to příteli o komunikaci a způsobu vyjádřování, což tady na "ábíčku" mnohým vůbec nejde a předháněj se ve výpisech jak smyslu zbaveni a přitom mnohdy absolutně zbytečně, ať jsou jakkoliv přesvědčující, přitom jim je nikdo nevyvrací a vymykají se původním dotazům, jako v tomto vlákně. Jen dodám k přiloženému snímku, je z desktopu a bez serveru, takže moje reakce v duchu tvého původního dotazu byla relevantní.

[aaa]

Představ si, že to pravděpodobně popisuje úplně přesně. A nelže. A umí číst hodnoty.

Možná sis mohl též všimnout, že se mu i na základě jeho prvního dotazu dostalo rad, které nikdo nezpochybnil. Ta diskuse, která tady probíhá následně, se týká něčeho jiného.

[Petr Fiedler]

+1

[theseuszn]

To "aaa":

Kdybych si měl všechno představovat a domýšlet nebo snad i vymýšlet, co není popsáno, tak se můžu přihlásit rovnou do soutěže taškářů. Řídím se i krom jiných pravidlem: "Jak se do lesa volá, tak se z lesa ozývá". Píšeš o diskusi, "která tu probíhá následně", že se týká něčeho jiného... Ano, všiml jsem si a je to zdejší specialita: z věty jednoduché tázací se stává věta složitá mlžící :D

[aaa]

Tazatel popsal problém a dostalo se mu správné odpovědi. To, co jsi psal ty, bylo "poněkud" mimo. Sorry, ale bylo. Dostalo se ti i vysvětlení, že tazatel nelže. Nevím, o co ti teď jde.

[Petr Fiedler]

To je u něj normální. Arogance a chytráctví. A znalosti nemá. V terminálu neumí nic a dovede jen přikládat ps's, urážet a chytračit.

[theseuszn]

Nebreč pořád a na mě se vy*er, já na Ábíčku nepředvádím ty zoufalosti jako ty :D

[Petr Fiedler]

Jenom potvrzuješ co jsem napsal - arogance a chytráctví.

[theseuszn]

Nešlo o nic jiného, než o to, že takovou podivnou záležitost ve "var" v LM nemám, jak psal tazatel v původním sdělení, proto jsem stav z mého LM informativně sdělil. Že překrucuješ moji formulaci mě mrzí a navíc jsem o tazateli nepsal že lže, to bych si nedovolil, psal jsem, že mi z jeho sdělení vychází "to lhaní a nečteni" a to samozřejmě není totéž, jako kdybych přímo napsal, že to tak je a navíc jsm se za své nešťastné vyjádření i omluvil.

[lertimir]

No tazatel jistě nelže. Složku "nesmyslný název" a ve složce soubory "system@nesmyslnynazev...journal" vzhledem k tomu, oba nesmyslné názvy jsou hexa číselné řady o délce 32 znaků (tedy 128bitů) usuzuji, že jsou to MD5 hashe něčeho - složka patrně instalace a soubory něčeho specifického k bootu (u user k session), protože po rebootu se číslo změní a ve stejné složce to zůstane.

# root @ system in /var [20:13:34] C:1
$ ll log/journal 
celkem 0
drwxr-sr-x+ 1 systemd-journal-remote systemd-journal-remote   0 19. čen  2016 remote
drwxr-sr-x+ 1 root                   systemd-journal        14K 18. lis 07.14 36045237ff4d4f07a6169708d88c9648

# root @ system in /var [20:23:43] 
$ ll log/journal/36045237ff4d4f07a6169708d88c9648 
celkem 4,1G
-rw-r-----+ 1 root systemd-journal  72M  1. lis 02.51 system@bbbb6bdb570747d19fe3e5dedf05b634-0000000000000001-000596109703ae3a.journal
-rw-r-----+ 1 root systemd-journal  64M  1. lis 06.25 system@bbbb6bdb570747d19fe3e5dedf05b634-0000000000344319-0005963f3476c390.journal
-rw-r-----+ 1 root systemd-journal  64M  4. lis 01.06 system@bbbb6bdb570747d19fe3e5dedf05b634-0000000000359d5e-0005964230bc7bd3.journal
-rw-r-----+ 1 root systemd-journal  72M  4. lis 06.00 system@bbbb6bdb570747d19fe3e5dedf05b634-00000000003712ae-0005967a1671bb9e.journal
-rw-r-----+ 1 root systemd-journal  80M 25. zář 01.45 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000000a30f4-0005935507b907fc.journal
-rw-r-----+ 1 root systemd-journal  80M 25. zář 01.53 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000000c98a2-00059355229987a2.journal
-rw-r-----+ 1 root systemd-journal  80M 28. zář 06.16 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000000efff4-000593553e596823.journal
-rw-r-----+ 1 root systemd-journal  56M 19. zář 21.58 system@dd0d8eaa3f4d415bac42c02d0567c80c-0000000000000001-0005922320a10fae.journal
-rw-r-----+ 1 root systemd-journal  88M 25. zář 01.23 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000002b78e-000592ed69f5b0c8.journal
-rw-r-----+ 1 root systemd-journal  80M 25. zář 01.30 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000005619d-00059354d2e5458d.journal
-rw-r-----+ 1 root systemd-journal  80M 25. zář 01.38 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000007c96d-00059354ed193ca3.journal
-rw-r-----+ 1 root systemd-journal  80M 14. říj 01.22 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000001c3e79-000594d2e15c18d4.journal
-rw-r-----+ 1 root systemd-journal  80M 14. říj 01.33 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000001e94fa-000594d30776486a.journal
-rw-r-----+ 1 root systemd-journal  72M 30. zář 01.48 system@dd0d8eaa3f4d415bac42c02d0567c80c-0000000000117417-0005939542f1838d.journal
-rw-r-----+ 1 root systemd-journal  72M 30. zář 13.08 system@dd0d8eaa3f4d415bac42c02d0567c80c-0000000000132e76-000593b9c08a2c09.journal
-rw-r-----+ 1 root systemd-journal  56M  1. říj 13.57 system@dd0d8eaa3f4d415bac42c02d0567c80c-0000000000149f30-000593c341c4d160.journal
-rw-r-----+ 1 root systemd-journal  72M  4. říj 17.55 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000015ead2-000593d80f628fc7.journal
-rw-r-----+ 1 root systemd-journal  88M 14. říj 01.01 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000017904b-00059417bbd22eb1.journal
-rw-r-----+ 1 root systemd-journal  80M 14. říj 01.12 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000019e83f-000594d2ba5c4521.journal
-rw-r-----+ 1 root systemd-journal  72M 28. říj 09.10 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000002a0ca3-000595f107f8cbfd.journal
-rw-r-----+ 1 root systemd-journal  72M 28. říj 12.43 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000002b65a7-000595f40795ec5f.journal
-rw-r-----+ 1 root systemd-journal  72M 28. říj 16.17 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000002cbf46-000595f7032cfcd4.journal
-rw-r-----+ 1 root systemd-journal  72M 28. říj 19.56 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000002e18fe-000595f9fe8ade51.journal
-rw-r-----+ 1 root systemd-journal  72M 28. říj 23.31 system@dd0d8eaa3f4d415bac42c02d0567c80c-00000000002f7296-000595fd0d27d0b8.journal
-rw-r-----+ 1 root systemd-journal  80M 14. říj 01.44 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000020eb11-000594d32e61a906.journal
-rw-r-----+ 1 root systemd-journal  88M 22. říj 03.41 system@dd0d8eaa3f4d415bac42c02d0567c80c-0000000000234328-000594d355a3e859.journal
-rw-r-----+ 1 root systemd-journal  80M 28. říj 01.59 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000026d8d7-00059575e63024d0.journal
-rw-r-----+ 1 root systemd-journal  64M 28. říj 05.35 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000028b3b1-000595ee02690028.journal
-rw-r-----+ 1 root systemd-journal  72M 29. říj 03.06 system@dd0d8eaa3f4d415bac42c02d0567c80c-000000000030cd51-000596000f7becdb.journal
-rw-r-----+ 1 root systemd-journal  64M  6. srp 14.32 system@f27d82f659e2458ab8f6b2a878ed2788-00000000010531a1-00058d2981556178.journal
-rw-r-----+ 1 root systemd-journal  64M 19. lis 20.22 system.journal
-rw-r-----+ 1 root systemd-journal 8,0M  6. srp 19.26 system@00058f761ee55f72-a6c4a3dd8c917fda.journal~
-rw-r-----+ 1 root systemd-journal  16M 21. srp 19.52 system@000590a43b347ea3-aaf65387104f8043.journal~
-rw-r-----+ 1 root systemd-journal  40M  4. zář 22.43 system@000591c0437113bc-8f1101e58a76d572.journal~
-rw-r-----+ 1 root systemd-journal  24M 27. srp 11.07 system@00059115988f42b3-a17eac090a289d06.journal~
-rw-r-----+ 1 root systemd-journal  24M 29. srp 12.10 system@0005913eb84bcd69-c411b47d3a6b0646.journal~
-rw-r-----+ 1 root systemd-journal  56M  9. zář 20.30 system@00059222fbac041d-141864debebeefd0.journal~
-rw-r-----+ 1 root systemd-journal 8,0M  9. zář 20.40 system@0005922320a2f344-613178924008f4a4.journal~
-rw-r-----+ 1 root systemd-journal  32M 29. říj 19.14 system@0005961097065a12-c36bfc3a79ed1dc6.journal~
-rw-r-----+ 1 root systemd-journal  64M 12. lis 19.41 system@0005972a9a798969-b5a9b89872bba4a0.journal~
-rw-r-----+ 1 root systemd-journal  16M 16. lis 17.49 system@0005977980744289-ebc69d9c3bca4a69.journal~
-rw-r-----+ 1 root systemd-journal  72M 18. lis 00.16 system@03a738453d58466dadd35e9a56c9a906-0000000000000001-0005977980724f46.journal
-rw-r-----+ 1 root systemd-journal  64M 18. lis 03.44 system@03a738453d58466dadd35e9a56c9a906-00000000003c6d13-0005979304225a1c.journal
-rw-r-----+ 1 root systemd-journal  64M 18. lis 07.14 system@03a738453d58466dadd35e9a56c9a906-00000000003dc6b5-00059795ee9ad2f2.journal
-rw-r-----+ 1 root systemd-journal  56M 19. srp 18.17 system@429cb1d5a1484622983391b77ff6b70e-0000000000000001-00058f761ee40608.journal
-rw-r-----+ 1 root systemd-journal  72M  9. zář 03.12 system@858a89f5c13846af83c266fbf2c1bd22-0000000000000001-000591c0436f165b.journal
-rw-r-----+ 1 root systemd-journal  64M  9. zář 06.41 system@858a89f5c13846af83c266fbf2c1bd22-000000000003431f-000592147a4d77d4.journal
-rw-r-----+ 1 root systemd-journal  64M  9. zář 10.10 system@858a89f5c13846af83c266fbf2c1bd22-000000000004a3d5-0005921765ba583d.journal
-rw-r-----+ 1 root systemd-journal  64M  9. zář 13.39 system@858a89f5c13846af83c266fbf2c1bd22-0000000000060a10-0005921a5272a7c7.journal
-rw-r-----+ 1 root systemd-journal  72M  9. zář 17.10 system@858a89f5c13846af83c266fbf2c1bd22-0000000000076d98-0005921d3d64447e.journal
-rw-r-----+ 1 root systemd-journal  64M 19. srp 18.17 user-1000@a9ee6a1e3dda4b9094893892bee738dc-0000000000000642-00058f7621c06524.journal
-rw-r-----+ 1 root systemd-journal  72M  9. zář 03.12 user-1000@d00d284f6a6d4fceb9a89c474b6e53b5-0000000000000661-000591159b8cf58f.journal
-rw-r-----+ 1 root systemd-journal 8,0M  9. zář 06.41 user-1000@d00d284f6a6d4fceb9a89c474b6e53b5-0000000000034386-000592147b63bb3f.journal
-rw-r-----+ 1 root systemd-journal  16M  9. zář 10.10 user-1000@d00d284f6a6d4fceb9a89c474b6e53b5-000000000004a439-000592176691e0f7.journal
-rw-r-----+ 1 root systemd-journal 8,0M  9. zář 13.39 user-1000@d00d284f6a6d4fceb9a89c474b6e53b5-0000000000060a9d-0005921a53b64419.journal
-rw-r-----+ 1 root systemd-journal 8,0M  9. zář 17.10 user-1000@d00d284f6a6d4fceb9a89c474b6e53b5-0000000000076dc4-0005921d3dd67b7d.journal
-rw-r-----+ 1 root systemd-journal 8,0M 25. zář 01.45 user-1000@f762727929f04b9c9051408337bdb55b-00000000000a47a3-0005935508bf7e43.journal
-rw-r-----+ 1 root systemd-journal 8,0M 25. zář 01.53 user-1000@f762727929f04b9c9051408337bdb55b-00000000000e286c-0005935534c86b9b.journal
-rw-r-----+ 1 root systemd-journal 128M 19. zář 21.58 user-1000@f762727929f04b9c9051408337bdb55b-0000000000000f6a-0005922339663aa8.journal
-rw-r-----+ 1 root systemd-journal  32M 25. zář 01.23 user-1000@f762727929f04b9c9051408337bdb55b-000000000002b762-000592ed624ec116.journal
-rw-r-----+ 1 root systemd-journal 8,0M 25. zář 01.30 user-1000@f762727929f04b9c9051408337bdb55b-00000000000599cd-00059354d54fd515.journal
-rw-r-----+ 1 root systemd-journal 8,0M 25. zář 01.38 user-1000@f762727929f04b9c9051408337bdb55b-000000000007cee9-00059354ed537e81.journal
-rw-r-----+ 1 root systemd-journal  24M 28. zář 06.16 user-1000@f762727929f04b9c9051408337bdb55b-000000000010219f-000593554c03b214.journal
-rw-r-----+ 1 root systemd-journal  24M 30. zář 01.48 user-1000@f762727929f04b9c9051408337bdb55b-0000000000117421-00059395438c8a5f.journal
-rw-r-----+ 1 root systemd-journal 8,0M 30. zář 13.08 user-1000@f762727929f04b9c9051408337bdb55b-0000000000133887-000593b9cc772284.journal
-rw-r-----+ 1 root systemd-journal  16M 19. lis 20.22 user-1000.journal
-rw-r-----+ 1 root systemd-journal  16M  6. srp 19.26 user-1000@00058f7621c1270c-7a89833df7d873bc.journal~
-rw-r-----+ 1 root systemd-journal  24M 21. srp 20.06 user-1000@000590a46ff379c2-1ed3a48a9bfbd169.journal~
-rw-r-----+ 1 root systemd-journal  24M 27. srp 11.07 user-1000@000591159b8e81cb-71120e066f71a338.journal~
-rw-r-----+ 1 root systemd-journal 8,0M  9. zář 20.47 user-1000@000592233966fdf4-e623e1ae09112c90.journal~
-rw-r-----+ 1 root systemd-journal 8,0M  1. říj 13.58 user-1000@000593d8124336b8-febe0cf482660cce.journal~
-rw-r-----+ 1 root systemd-journal 8,0M 14. říj 01.08 user-1000@9925096988304a55a2805c3fea1aec2b-00000000001ac648-000594d2c8d957ba.journal
-rw-r-----+ 1 root systemd-journal 8,0M 14. říj 01.18 user-1000@9925096988304a55a2805c3fea1aec2b-00000000001c49cb-000594d2e215887f.journal
-rw-r-----+ 1 root systemd-journal 8,0M 14. říj 01.33 user-1000@9925096988304a55a2805c3fea1aec2b-00000000001f907d-000594d317ba77f4.journal
-rw-r-----+ 1 root systemd-journal  16M  4. říj 17.55 user-1000@9925096988304a55a2805c3fea1aec2b-000000000015f182-000593d8123f4868.journal
-rw-r-----+ 1 root systemd-journal  48M 14. říj 00.58 user-1000@9925096988304a55a2805c3fea1aec2b-0000000000179740-00059442e38961e5.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 09.06 user-1000@9925096988304a55a2805c3fea1aec2b-00000000002a1f1f-000595f130f16b83.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 12.43 user-1000@9925096988304a55a2805c3fea1aec2b-00000000002b70ff-000595f41ff62b01.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 16.17 user-1000@9925096988304a55a2805c3fea1aec2b-00000000002cc4a7-000595f70efae6e0.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 19.50 user-1000@9925096988304a55a2805c3fea1aec2b-00000000002e311c-000595fa33a48e27.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 23.25 user-1000@9925096988304a55a2805c3fea1aec2b-00000000002f7c22-000595fd22a94cef.journal
-rw-r-----+ 1 root systemd-journal 8,0M 14. říj 01.44 user-1000@9925096988304a55a2805c3fea1aec2b-0000000000220995-000594d3419f3243.journal
-rw-r-----+ 1 root systemd-journal 112M 22. říj 03.40 user-1000@9925096988304a55a2805c3fea1aec2b-0000000000234761-000594d355e4de01.journal
-rw-r-----+ 1 root systemd-journal  24M 28. říj 01.59 user-1000@9925096988304a55a2805c3fea1aec2b-000000000026d8db-00059575eb552734.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 05.35 user-1000@9925096988304a55a2805c3fea1aec2b-000000000028b815-000595ee0c47f462.journal
-rw-r-----+ 1 root systemd-journal 8,0M 18. lis 03.44 user-1000@9925096988304a55a2805c3fea1aec2b-00000000003c7cd5-00059793262643b6.journal
-rw-r-----+ 1 root systemd-journal 8,0M 18. lis 07.10 user-1000@9925096988304a55a2805c3fea1aec2b-00000000003dd8c7-00059796152b03b0.journal
-rw-r-----+ 1 root systemd-journal 8,0M 29. říj 03.06 user-1000@9925096988304a55a2805c3fea1aec2b-000000000030ce51-0005960011ae0f39.journal
-rw-r-----+ 1 root systemd-journal  16M  1. lis 02.49 user-1000@9925096988304a55a2805c3fea1aec2b-000000000032374e-00059603305ecf4b.journal
-rw-r-----+ 1 root systemd-journal 8,0M  1. lis 06.25 user-1000@9925096988304a55a2805c3fea1aec2b-000000000034437e-0005963f357341e6.journal
-rw-r-----+ 1 root systemd-journal  16M  4. lis 01.06 user-1000@9925096988304a55a2805c3fea1aec2b-000000000035a47e-00059642408651cd.journal
-rw-r-----+ 1 root systemd-journal 8,0M  4. lis 05.56 user-1000@9925096988304a55a2805c3fea1aec2b-00000000003712b9-0005967a167533b4.journal
-rw-r-----+ 1 root systemd-journal  80M 18. lis 00.14 user-1000@9925096988304a55a2805c3fea1aec2b-0000000000387001-0005967e317f3162.journal
-rw-r-----+ 1 root systemd-journal 8,0M 28. říj 01.59 user-1002@0296e9330b5e4e7290fe125115f56871-000000000027444e-00059599f2ad334f.journal

Můj log má 4.1G, jak je vidět a ve /var má sice lib 2,7G, ale nejvíce má cache, která nese archiv aktualizovaných balíčků Archu od spuštěnísystému v roce 15 a nyní má 91G a budu to muset někdy vyčistit.

[Andrej]

Jaký přesně problém se snažíš vyřešit? Proč přesně by mělo být 1,3 GB logů cosi znepokojivého? Zabírá to většinu disku? To asi ne, že jo… Roste to dál a neomezeně? Ráčil ses obtěžovat prohledat ty logy vhodnou utilitou, jestli se tam náhodou neopakuje stále dokola podobný problém, který by generoval většinu záznamů?