Jean-Baptiste Kempf na svém blogu představil novou verzi 9.0 "Lei" kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie).
Richard Hughes oznámil, že službu Linux Vendor Firmware Service (LVFS) umožňující aktualizovat firmware zařízení na počítačích s Linuxem, nově sponzoruje také společnost NVIDIA.
Edvard Rejthar na blogu zaměstnanců CZ.NIC představil svou aplikaci SlideRshow (GitHub). Funguje jako prohlížeč fotek, ale i jako jejich organizér a prezentátor. Neinstaluje se, běží přímo v prohlížeči. Bez serveru. Offline.
Kermit, tj. protokol pro přenos souborů, vznikl před 45 lety. Při této příležitosti byla po 15 letech od vydání poslední stabilní verze 9.0.302 vydána nová stabilní verze 11 implementace C-Kermit. S podporou IPv6.
První verze konverzního nástroje Pandoc byla vydána před 20 lety. Jeho autor John MacFarlane při tomto výročí rekapituluje jednotlivé etapy vývoje a přidávání nových funkcí – rozšíření nejen Markdownu a podporu mnoha dalších formátů.
Srpen přinesl nejen další spalující vedro, ale také Virtuální Bastlírnu s neméně žhavými novinkami. Využijte tedy předpovědi na deštivý čtvrteční večer a od 20:00 se připojte online k tomuto neformálnímu setkání kutilů, techniků a vědců, kde se strahovskými bastlíři proberete nejzajímavější věci, na které jste narazili za poslední měsíc. Pokud jde o novinky, řeč zcela jistě přijde na systém INDX pro tiskárny Průša, který na konci
… více »Firma T-Mobile blokovala „dezinformační web“ AC24 bez toho, aniž by k tomu měla závazný pokyn orgánů veřejné moci. Píše to ve svém rozsudku Městský soud v Praze, který po čtyřech letech uzavřel kauzu blokace zmíněného webu. Operátor musí uhradit škodu ve výši 35 tisíc korun. Advokát společnosti T-Mobile se snažil i u odvolacího senátu argumentovat tím, že firma jednala v dobré víře, když na stránky omezila přístup poté, co ji k tomu vyzvalo
… více »Padla obžaloba v bitcoinové kauze. Státní zástupkyně chce pro Blažka 6,5 roku vězení, pro Titze 8 let.
Z aktuálních globálních statistik společnosti Statcounter: na desktopu má Linux celosvětově podíl 7,53 % (USA 11,92 %, Česko 4,31 %, Slovensko 4,36 %) a Firefox celosvětově podíl 6,51 % (USA 10,86 %, Česko 11,07 %, Slovensko 13,61 %).
Na GitHubu byl publikován seznam 55 kritických bezpečnostních chyb v SQLite s přiřazenými CVE čísly. JFrog Security informuje, že se jedná jenom o AI slop, části kódu na které CVE odkazují, v daných verzích vůbec neexistují. Upozorňuje také, že čísla CVE jsou přiřazována bez ověřování.
Ř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.
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:
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.
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
Tiskni
Sdílej: