Description of problem: unable to rotate journal log. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. click up a terminal 2. su - root 3. systemctl kill --signal=SIGUSR1 systemd-journald.service 4. systemctl kill --signal=SIGUSR2 systemd-journald.service 5. journalctl | grep "cgroup subsys cpuset"
Blocks: (none) => 8039Assignee: bugsquad => mageia
The tests/expectations here seem wrong. A rotated journal doesn't mean much by itself as all journal files will be merged and read by journalctl and presented as a single stream anyway, so the step 5 test doesn't prove much. I just tried step 4 and my journal was indeed rotated happily (looking in /var/log/journal/`cat /etc/machine-id`/ to confirm).
Status: NEW => RESOLVEDResolution: (none) => INVALID
(In reply to comment #1) > The tests/expectations here seem wrong. Well, My Expectations were to not have a bunch of previous problems in the log. Example: I want to remove all the "logs" and several reboots are preformed over the next three days. Now I want to search the logs for failure. I do not expect to see failure before three days ago without having to remember to add --since=whatever on every command when I look into the database much less so for my system auditing cron job. :( > A rotated journal doesn't mean much by itself as all journal files will be > merged If you mean the files in /var/log/journal/ show up in a search, that is not true. I rotated my 4 day old log, ~29 meg, removed the *@* and *~ files and rebooted. New system.journal file went back to 3.98 meg. and journalctl |grep failed still showed failures back to clean system install date. :( System has been pretty idle since I can not use it normally. Not being to run mythfrontend because of urpmi transcode problem keeps me using the system on a daily basis. Hmm, let's see, idle system used ~29 meg in 4 days works out to 365 divided by 4 times 29m = 2,646.25. Hate to see what a half busy system log is going to consume. :-(
Well, that's just it. A rotated journal is not very much like a rotated syslog. They are two different beasts. Keep in mind that if you enable Forward Secure Sealing, then you may want your journal to be rotated every 5 or 10 minutes so that you reduce the integrity violation window in the event of an attack. In such setups, rotated files should be masked away. This is very different to archiving which is a different story entirely. I'm not sure what the long term goals are there regarding archival. Keep in mind that you can configure the journal storage size such that each journal itself will be kept to a known size and that journals general will only take up a certain percentage of storage space on the partition. On my active, daily use system: Logs begin at Tue, 2012-10-23 10:54:10 BST, end at Mon, 2012-10-29 09:35:47 GMT. My journals take up 18M+4.5M = 22.5M for system and 3.7M+3.6M = 7.3M for the user journal. That's not too crazy in my book (especially as I enable a lot of debuging typically). Comparing the disk sizes to the byte count in a syslog style expression of the data: journalctl --all | wc -c 20761264 = 19.8M which isn't too crazy in my book considering the extra metadata stored by the journal. I do agree that some nice compressed archival system would be nice tho'. I've asked about any future plans for this on the list.
OK, I may have been talking bollocks about the sizes as I was discarding some files ending in ~ that I probably shouldn't have been discarding. It also seems I don't have an option for xz compression in the journal itself so the files are uncompressed generally. I've enabled that in the build now, so hopefully if you nuke out the journals after upgrading, you'll see some good size improvements!
Hmm, I'm having a bad morning. Seems the old build had the build dep via some other route... I'll investigate why I'm seeing such dramatic size differences.
(In reply to comment #4) > I've enabled that in the build now, so hopefully if you nuke out the journals My new_boot_logs script was already scraping the journals. _log_dir=/var/log/journal/$(cat /etc/machine-id) if [ -e $_log_dir ] ; then /bin/rm -f $_log_dir/* fi What I still can not find, is the last bit of journal with some history. :( I really appropriate all your time spent on Mageia and us dumb users. Any chance you can poke someone about the 8084 transcode problem. :)