On Thu, 27 Dec 2018 09:36:28 +0000 Dmitry Bogatov <kact...@debian.org> wrote:
> [2018-12-26 03:58] Alex Efros <power...@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
