Portál AbcLinuxu, 29. ledna 2026 13:14
Řešení dotazu:
/var/log
Ty máš křišťálovou kouli, že víš co mu zabírá nejvíc místa? Každopádně truncate nic nemaže. Je to použitelné řešení v situaci, kdy máš zaprásknutý disk až do mrtě.
ls =l ? Ak tie rôzne čísla porovnáš, tak sa dostaneme ku sparse súborom, a na čo som narážal pri reakcii "nejvíce zbytnělý log ve /var/log". Medzi také súbory ktoré sa začiatočníkovi javia ako moc veľké patria vo /var/log aj [last,fail]log.
Ale s tým truncate, tak mi prezraď ako uvoľní miesto na disku ak sú inody skracovaného súboru obsadené bežiacim procesom. Skús to vysvetliť tvojím začiatočníckym spôsobom.
Toľko ku tým tvojím žvástom akými sa chváli lamička ktorú na MDD nikto nechce.
/var/log má smysl jen když něco řešíš. U lamy tedy většinou žádný. Truncate používám jen v případě, že potřebuji uvolnit alespoň tolik místa, aby zafungoval journalctl. Zkrátím velikost na 0 bajtů, ty stávající data se zahodí a ten proces začne zapisovat nová. Si to vyzkoušej mameluku.
Ohľadne tej infraštruktúry ktorú akože spravuješ, tak by som poprosil sieťový rozsah. Rád si ho preventívne zablokujem.
Beze všeho: 192.168.x.y – za x a y si dosaď libovolné číslo od 0 do 255
Mimochodem, ten tvůj /var/log/wtmp obsahuje data, která jsou úplně k hovnu. Viz /var/log/wtmp
Je to jen zbytečný bordel zabírající místo, který se při restartu může s klidnou duší zahodit, protože (u mne) jsou klíčové informace uložené jinde, ve výrazně srozumitelnější formě. Soubor, ve kterém jsou veškeré informace za posledních 334 dní má všeho všudy 65MB
A největší log /var/log/lastlog má u mne trapných 100MB
Je rok 2025. Na co systmd-journald poštve nějaké zkracování, to je věcí jeho konfigurace. A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.
Budeš se divit, ale jo. Speciálně u zaplácnutého Btrfs. A příkaz journalctl --vacuum-time=1d sem tam také použiju.
Nevím, no. Když mám podezření, že je něco špatně, podívám se na journalctl -f. Pokud se něco objevuje častěji než jednou za (se)kundu, obvykle je potřeba řešit příčinu toho problému, ne až následek. Dokonce mám na některých stojích alert odvozený od „produktivity“ journalctl -f.
Přečti si prosím ještě jednou, od samého počátku tuhle diskuzi prosím.
Pořádné sračky. Až to bolí číst. Hlavně tedy ten truncate.
Mysli si o tom co chceš, pro mne je důležité, že to funguje0.
(0) Před 15+ lety by to možná fungovalo [pozn. red.].
Pohled do kalendáře mě utvrzuje v jistotě, že nezáleží na tom, co si kdo myslí. Věci v té strohé realitě prostě už nějak jsou.
21.6.2025 16:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
zkrácením (binárních, komprimovaných) logůMožná mám journald špatně nastavený, ale zabírá mi mnohem víc prostoru, než ekvivalentní textová reprezentace. Konkrétní experimenty:
to z tebe teda zbyla troska
journalctl | wc -c ukáže 1325903166 (1.3 giga), ale /var/log/journal má 4.3 GB. Člověk by čekal, že tam ještě budou efektivně uložené timestampy a další metadata.
Textový /var/log/syslog, do kterého podle mě přeposílám veškeré zprávy co jsou v journalu, má od neděle 327 MB. journalctl --since "6 days ago"| wc -c ukáže 267377143 (267 mega), čili řádově by to odpovídalo. Následně jsem spustil journalctl --vacuum-time=6d a /var/log/journal se zmenšilo na 782 MB, stále je tedy 2-3x větší než hloupý textový syslog.
Obsah adresáře /var/log/journal jsem zkopíroval a zkusil zkomprimovat defaultním gzipem. Zmenšil se na 175 MB (4.5x). To znamená, že původní data vůbec nejsou komprimována, naopak.
Též jsem gzipem zkomprimoval textový /var/log/syslog. Ten se zkomprimoval na 22.5 MB (skoro 8x lépe než komprimovaný binární journal). Tedy ani například transparentně komprimující souborový systém by s journalem tolik nepomohl.
Naposledy jako zpětná kontrola: teď když jsem udělal vacuum za 6 dní, tak mám
journalctl | wc -c: 245 megajournalctl | gzip | wc -c: 12.5 megadu -sh --si /var/log/journal/: 782 megaJo, to netuším, co je špatně. Přičiním jenom několik „stating the obvious“ poznámek:
-u nebo podle času, takže se nedá srovnat 1:1 s tím, co ukládá journald.man journald.conf neklame, implicitně se komprimují jen záznamy (== jednotlivé „zprávy“ v logu, velikostí něco mezi „řádkou“ a „backtrace“ ), pokud přesáhnou 512 B. Tohle se sice dá nastavit (snížit), ale pokud má každý záznam svůj oddělený kontext/slovník pro kompresi, bude taková komprese velmi neúčinná.Seal= (FSS), což v některých distrech může být implicitně nastavené při instalaci, bez vědomého přičinění uživatele, můžou data logů ještě víc nabobtnat./var/log/journal není příliš fair srovnání, protože tam je uložené všechno z journalctl + všechno z journalctl --user + všechno z journalctl --user pro všechny ostatní uživatele.Ještě pro upřesnění, co jsem myslel tímto:
A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.
Výše zmíněné checksumy zajistí, že poškození (náhodné zkrácení) binárních logů od journald učiní tyto soubory nečitelnými. Tudíž místo předvídatelného zkrácení dojde ke ztrátě dat z podstatné části příslušného souboru (výrazně větší než uříznutá část), popřípadě z celého souboru, který může journalctl odmítnout číst. A při každém přístupu přes journalctl se bude ukazovat chybová hláška o poškozeném souboru.
Proto↑ jsem příslušnou „radu“ považoval za kolosální nesmysl. Měl jsem se vyjádřit přesněji.
3.8.2025 21:33
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
df -h, protože může být nějak hloupě rozdělený. Dál lze pátrat po velikosti jednotlivých adresářů příkazem du viz příklady třeba zde.
Vlákno bylo přesunuto do samostatné diskuse.
sudo bash
cd /
du -sh * |sort -h
zoradi podla velkosti
3.6.2025 14:17
|🇵🇸 | skóre: 94
| blog:
3.8.2025 21:28
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.