On Sat, 29 Dec 2018 18:33:06 +0000
Dmitry Bogatov <KAction_at_debian.org> wrote:
> [2018-12-27 08:07] Steve Litt <slitt_at_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
Received on Sun Dec 30 2018 - 01:20:29 UTC