Fwd: [PATCH] runit-2.1.2 svlogd: never prune the in-progress .u

From: Mike Pomraning <mjp_at_pilcrow.madison.wi.us>
Date: Wed, 29 Apr 2015 14:56:22 -0500

When rotating, svlogd treats unfinished .u files and saved .s files alike,
deleting the oldest it finds.

However, if the system clock has stepped backward, the in-progress .u file,
which is input for the post-rotation processor, may appear older than any
rotated .s files. In that case, svlogd becomes wholly unresponsive, stuck
in a pathological loop trying to process a file that doesn't exist, and
must be SIGKILLed.

The below patch appears to address the issue for me, and is an improvement
over my previous attempt to simply ignore (rather than loop forever around)
the ENOENT. svlogd will still rotate any older (interrupted) .u files it
finds, as normal, but it will leave the about-to-be-processed .u untouched.

Gerit, please consider this issue for the next release of runit. It's
acceptable IMO that funny clocks might degrade time-based log rotation,
perhaps even losing data, but not that a clock jump would unrecoverably
hang the service.


--- src/svlogd.c.orig 2013-02-26 14:15:45.886549000 -0600
+++ src/svlogd.c 2015-04-28 23:50:41.116613675 -0500
_at__at_ -222,8 +222,10 @@ void rmoldest(struct logdir *ld) {
   DIR *d;
   direntry *f;
   char oldest[FMT_PTIME];
+ int will_process;
   int n =0;

+ will_process = (ld->fnsave[26] == 'u');
   oldest[0] ='A'; oldest[1] =oldest[27] =0;
   while (! (d =opendir(".")))
     pause2("unable to open directory, want rotate", ld->name);
_at__at_ -235,8 +237,12 @@ void rmoldest(struct logdir *ld) {
           warn2("unable to unlink processor leftover", f->d_name);
       else {
- ++n;
- if (str_diff(f->d_name, oldest) < 0) byte_copy(oldest, 27,
+ ++n; /* count .s and .u files ... */
+ if (str_diff(f->d_name, oldest) < 0)
+ /* ... but don't unlink our pending .u if the clock is funny */
+ if (! (will_process && (str_diff(ld->fnsave, f->d_name) == 0)))
+ byte_copy(oldest, 27, f->d_name);
       errno =0;
Received on Wed Apr 29 2015 - 19:56:22 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC