On Thu, 27 Dec 2018 09:36:28 +0000
Dmitry Bogatov <KAction_at_debian.org> wrote:
> [2018-12-26 03:58] Alex Efros <powerman_at_powerman.name>
> > Hi!
> >
> > I'm not sure is it good idea to include .u files in usual rotation
> > process at all, and especially handle them just like .s files. If
> > several crashes happens for some reason in a short period of time
> > this will result in deletion of all log files except last (say)
> > 10 .u files, which are usually small and may contain just one line.
> > Replacing 10MB of last logs with 10 last log lines doesn't sounds
> > like a nice idea.
> >
> > Possible "right" solution will be to keep same amount of last .u
> > files as configured for .s files, i.e. if we've configured to keep
> > last 10 files then we may have at most double amount (10 .u files
> > and 10 .s files). (I didn't checked mentioned patches, so maybe
> > they already works this way.)
>
> Why would it be wrong to just keep appending to `current' instead of
> moving it to `.u' file? (see my patch at end of bug thread)
>
> And this issue happens not only on crash, it happens after every
> termination of svlogd, due any signal. I would agree that SIGKILL is
> crash, but issue reproduces with SIGINT and SIGTERM.
The right solution is to leave the runit code as-is, until both the
exact mechanism and intent of the existing code is understood, and the
exact reproduction sequence *in the wild* is completely understood.
Until then, any change to runit code would be bandaging the symptom
rather than fixing the root cause. And we all know that
symptom-bandaging leads to side effects, usually bad ones. The guy who
jumpers across a circuit breaker because the circuit breaker flips
every few days just might burn down his house.
The Bug Filer (BF) disliked that there were too many .u files. That
symptom can be fixed in a way that's a couple orders of magnitude less
likely to produce side effects. Simply run a program, invoked by cron,
that deletes .u files over a certain age, as long as it doesn't delete
the latest .u file. This does pretty much what the BF needs, leaves
recent .u files available for diagnostics, and doesn't touch any runit
code.
From what Gerrit wrote you, runit is now pretty much
unmaintained, so unless someone steps forward ready, willing and able
to master the entire runit code base and architecture, runit code
probably shouldn't be messed with.
I'll be glad to write the program to be run from the cron job. I can
have it for you within 4 days, and I'll put any free software license
on it that you/Debian wants.
There's another alternative for the BF and anyone else inconvenienced
by this symptom: They can switch to s6. In my opinion, runit and s6 are
very close cousins, at least compared to the likes of systemd,
sysvinit, OpenRC, Busybox init and the like. Unlike runit, s6 is
constantly maintained, so any bugs can be solved by the actual author
rather than distro packagers. If Debian doesn't yet have an s6 package,
perhaps a packager could be found, and a Debian s6 (and s6-rc) package
can be made.
Thank you so much for packaging runit for Debian. Runit is a wonderful
supervisor/init that provides a wonderful alternative to the ancient
init, the massively entangled monolithic init, and the init that can't
even respawn (or couldn't as of 3 years ago). Keep up the good work.
SteveT
Steve Litt
December 2018 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
Received on Thu Dec 27 2018 - 13:47:16 UTC