summaryrefslogtreecommitdiff
path: root/po/pl.po
diff options
context:
space:
mode:
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2013-06-07 22:01:03 -0400
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2013-06-10 10:10:07 -0400
commitcbd671772c9ce053a7050ddd29de170eb9efac7e (patch)
tree7534200fb9acebf8ef32497ac3137c86381a8443 /po/pl.po
parent5cb24cd32bce87cc618b857c059f1187e03d2b24 (diff)
journal: letting (interleaved) seqnums go
In the following scenario: server creates system.journal server creates user-1000.journal both journals share the same seqnum_id. Then server writes to user-1000.journal first, and server writes to system.journal a bit later, and everything is fine. The server then terminates (crash, reboot, rsyslog testing, whatever), and user-1000.journal has entries which end with a lower seqnum than system.journal. Now server is restarted server opens user-1000.journal and writes entries to it... BAM! duplicate seqnums for the same seqnum_id. Now, we usually don't see that happen, because system.journal is closed last, and opened first. Since usually at least one message is written during boot and lands in the system.journal, the seqnum is initialized from it, and is set to a number higher than than anything found in user journals. Nevertheless, if system.journal is corrupted and is rotated, it can happen that an entry is written to the user journal with a seqnum that is a duplicate with an entry found in the corrupted system.journal~. When browsing the journal, journalctl can fall into a loop where it tries to follow the seqnums, and tries to go the next location by seqnum, and is transported back in time to to the older duplicate seqnum. There is not way to find out the maximum seqnum used in a multiple files, without actually looking at all of them. But we don't want to do that because it would be slow, and actually it isn't really possible, because a file might e.g. be temporarily unaccessible. Fix the problem by using different seqnum series for user journals. Using the same seqnum series for rotated journals is still fine, because we know that nothing will write to the rotated journal anymore. Likely related: https://bugs.freedesktop.org/show_bug.cgi?id=64566 https://bugs.freedesktop.org/show_bug.cgi?id=59856 https://bugs.freedesktop.org/show_bug.cgi?id=64296 https://bugs.archlinux.org/task/35581 https://bugzilla.novell.com/show_bug.cgi?id=817778 Possibly related: https://bugs.freedesktop.org/show_bug.cgi?id=64293
Diffstat (limited to 'po/pl.po')
0 files changed, 0 insertions, 0 deletions