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: Sat, 29 Dec 2018 20:20:29 -0500	[thread overview]
Message-ID: <20181229202029.054723df@mydesk.domain.cxm> (raw)
In-Reply-To: <E1gdJQ3-0003hp-Gg@eggs.gnu.org>

On Sat, 29 Dec 2018 18:33:06 +0000
Dmitry Bogatov <KAction@debian.org> wrote:

> [2018-12-27 08:07] Steve Litt <slitt@troubleshooters.com>
> > > [ Dmitry Bogatov ]
> > > No, it is reproducible. See end of bug thread.  
> > 
> > Hi Dmitry,
> > 
> > Just so we're all on the same page, do you mean the end of
> > https://bugs.debian.org/916230 ? Could you please provide a message
> > number? I briefly looked over https://bugs.debian.org/916230, paying
> > particular attention to the later half, and could see no
> > reproduction sequence articulated. But sometimes I miss things.  
> 
> Sure. Message 17:
> 
>  Offending .u file is created by rename(2) call at line 532, in
>  logdir_open() function. It happens, when 'current' file exists,
>  non-executable and non-empty.
>  [...]

OK, so you can reproduce it with

echo bogus > current; chmod a-x current

That's pretty bizarre logic. I can understand why an empty current
would be overwritten --- what do you lose. But why only if it's
non-executable? Are they using the executable bit as some sort of flag
to keep processes from overwriting each others' writes to the file? I
once wrote a program in which, when an invocation of my program opened a
file, it set the file to read-write, and other invocations of my program
would decline to try to open a read-write version of the file. Bizarre,
but it worked, and no process clobbered the other.

I guess what I'm asking is this: Are you sure the original poster's
(OP's) .u files were caused by the rename call when non-empty non-exec
current exists, or is he experiencing a different reproduction sequence.

I still wouldn't mess with the existing code. I don't think anyone here
is positive of the purpose of the logic you described, and therefore
what side effects would happen if it were modified. The OP didn't have
enough .u files to really inconvenience him, and there are other ways of
getting rid of .u files. And the OP could switch to s6.
 
SteveT

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


  reply	other threads:[~2018-12-30  1:20 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
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 [this message]
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=20181229202029.054723df@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).