75 lines
3.0 KiB
Diff
75 lines
3.0 KiB
Diff
From 53113dc8254cae9a27e321e539d2d876677e61b9 Mon Sep 17 00:00:00 2001
|
|
From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
|
|
Date: Fri, 7 Jun 2013 22:01:03 -0400
|
|
Subject: [PATCH] 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
|
|
|
|
Conflicts:
|
|
src/journal/journald-server.c
|
|
---
|
|
src/journal/journald-server.c | 2 +-
|
|
1 file changed, 1 insertion(+), 1 deletion(-)
|
|
|
|
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
|
|
index cc52b8a..cde63c8 100644
|
|
--- a/src/journal/journald-server.c
|
|
+++ b/src/journal/journald-server.c
|
|
@@ -280,7 +280,7 @@ static JournalFile* find_journal(Server *s, uid_t uid) {
|
|
journal_file_close(f);
|
|
}
|
|
|
|
- r = journal_file_open_reliably(p, O_RDWR|O_CREAT, 0640, s->compress, s->seal, &s->system_metrics, s->mmap, s->system_journal, &f);
|
|
+ r = journal_file_open_reliably(p, O_RDWR|O_CREAT, 0640, s->compress, s->seal, &s->system_metrics, s->mmap, NULL, &f);
|
|
free(p);
|
|
|
|
if (r < 0)
|
|
--
|
|
1.8.2.1
|
|
|