supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Steve Litt <slitt@troubleshooters.com>
To: supervision@list.skarnet.org
Subject: Re: Log rotation issue with runit
Date: Wed, 26 Dec 2018 00:05:05 -0500	[thread overview]
Message-ID: <20181226000505.1e82b362@mydesk.domain.cxm> (raw)
In-Reply-To: <E1gbmvX-0003Sd-0r@eggs.gnu.org>

On Tue, 25 Dec 2018 13:39:17 +0000
Dmitry Bogatov <KAction@debian.org> wrote:

> Hello!
> 
> I am Debian maintainer of `runit' supervision suite. Recently, I
> received bug report [^1] about stray .u logfiles. After some
> investigation I found code, that caused issue, but it seems that it
> was written with some purpose, yet I fail to understand that purpose.
> 
> Author Gerrit Pape directed me here. Any clarification would be
> welcome! Please keep bug in thread.
> 
> [^1] https://bugs.debian.org/916230

It's vital that no code be changed until the exact nature of the
problem is understood and reproducible at will. The extra files
reported in the bug aren't nearly especially inconvenient when compared
to possible problems when modifying code that the code's author isn't
maintaining on a regular basis.

It would be interesting to see the dates and contents of the files:
That might shed some light on what's happening.

One person in this thread mentioned that .u files shouldn't be rotated
and deleted at all. If that's the case, a fairly simple cron job could
be made to delete all .u files older than a certain age except the
current/latest .u file. That would probably fix the inconvenience
endured by the bug reporter, without applying any premature fixes.

This seems to be an intermittent problem (not reproducible at will),
and very hard to reproduce by anyone but the bug reporter. If the
preceding sentence is true, it's possible it will never be solved. In
such a situation, a workaround becomes a legitimate tactic.

SteveT

Steve Litt 
December 2018 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21


  parent reply	other threads:[~2018-12-26  5:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-25 13:39 Dmitry Bogatov
2018-12-25 14:57 ` Alex Efros
2018-12-25 18:17 ` Guillermo
2018-12-25 18:30   ` Guillermo
2018-12-26  1:58   ` Alex Efros
2018-12-27  9:36     ` Dmitry Bogatov
2018-12-27 11:41       ` Laurent Bercot
2018-12-28  6:47         ` Jonathan de Boyne Pollard
2018-12-27 13:47       ` Steve Litt
2018-12-28  1:27         ` Guillermo
2018-12-27 23:39       ` Guillermo
2018-12-29 18:33         ` Dmitry Bogatov
2018-12-29 22:32           ` Guillermo
2018-12-28  6:57     ` Jonathan de Boyne Pollard
2018-12-26  5:05 ` Steve Litt [this message]
2018-12-27  9:36   ` Dmitry Bogatov
2018-12-27 13:07     ` Steve Litt
2018-12-29 18:33       ` Dmitry Bogatov
2018-12-30  1:20         ` Steve Litt
2018-12-30 10:04 ` Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181226000505.1e82b362@mydesk.domain.cxm \
    --to=slitt@troubleshooters.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).