[PATCH] ignore missing processor input, tolerate backward clock jump
svlogd freezes if a "!processor" is configured and a backward system clock
jump occurs during typical operation. There are two related issues.
First, svlogd cannot recover from missing input (".u") to its processor.
It loops infinitely, unresponsive to signals and EOF, spawning child
processors that die because of missing input. multilog has the same
behavior, for what it's worth.
Second, a system clock step into the past can cause svlogd's retention
logic to unlink its own processor input file, triggering the infinite loop.
"current" is rotated to an intermediate filename (".u") which appears to
be older than previously rotated (".s") files. The login unlinks
intermediate and finished log files alike.
The first problem is addressed by the patch below, which warns of ENOENT
but exits success to allow svlogd to proceed. (Note that a hostile or
clumsy sysadmin could also race to cause the infinite loop without this
patch.)
The second problem is subtler. Probably adopting multilog's
non-timestamped intermediate filenames is the easiest solution. Log
retention would still be confounded by the clock lag — that's unavoidable
given the design — but the processor could at least run.
Regards,
Mike
diff -up ./src/svlogd.c.orig ./src/svlogd.c
--- ./src/svlogd.c.orig 2015-01-27 23:08:44.192999283 -0600
+++ ./src/svlogd.c 2015-01-27 23:43:34.071998860 -0600
_at__at_ -140,8 +140,13 @@ unsigned int processorstart(struct logdi
if (verbose)
strerr_warn5(INFO, "processing: ", ld->name, "/", ld->fnsave, 0);
- if ((fd =open_read(ld->fnsave)) == -1)
+ if ((fd =open_read(ld->fnsave)) == -1) {
+ if (errno == error_noent) {
+ warn2("unable to open input for processor", ld->name);
+ _exit(0); /* no point in retrying processor */
+ }
fatal2("unable to open input for processor", ld->name);
+ }
if (fd_move(0, fd) == -1)
fatal2("unable to move filedescriptor for processor", ld->name);
ld->fnsave[26] ='t';
Received on Wed Jan 28 2015 - 20:06:27 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC