Dnia 2024-02-23, o godz. 13:02:00 Nicolas George <geo...@nsup.org> napisał(a):
> Mariusz Gronczewski (12024-02-23): > > That is not a feature systemd's logging have. > > That is what it seems, but I would like second opinions. > > > You'd have to make a > > rsyslogd rule to put it in one directory > > Thanks, but my question was about systemd's infrastructure. Answers > about the old systlog/logrotate infrastructure are a waste of time > since I already know how they work and they are amply documented > elsewhere. > So to say it short: It is horrid. There is no any sensible indexing or split between services or anything. Single spamming service can easily make it rotate out more important but much more rare log entries and there is nothing you can do about it. It is also woefully inefficient, with each "line" of log taking few times more than it does in text or even if thrown into SQLite database. For example: [13:37:01]cthulhu:/var/log/journal☠ ls -s -h /tmp/log.sqlite 79M /tmp/log.sqlite [13:37:12]cthulhu:/var/log/journal☠ sqlite /tmp/log.sqlite 'select count(*) from log' 386351 journalctl |wc -l 381770 [13:37:48]cthulhu:/var/log/journal☠ journalctl |dd of=/dev/zero bs=1M 0+15442 records in 0+15442 records out 63643115 bytes (64 MB, 61 MiB) copied, 5,47791 s, 11,6 MB/s du -h /var/log/journal/ 337M /var/log/journal/44cf6f547971fc33309d1e9e000002e7 337M /var/log/journal/ (I've raised a bug 8 years ago about it https://github.com/systemd/systemd/issues/2460 ) To summarize: the ~61MB of resulting text of logs takes around 337MB on disk when saved by journald, ~80MB in sqlite (~103MB when I added index for time and process). Use the old ways you know, it's a waste of time to try to wrangle journald to do what you want. -- Mariusz Gronczewski (XANi) <xani...@gmail.com> GnuPG: 0xEA8ACE64 https://devrandom.eu