Re: Is s6/s6-rc ready to be the ubiquitous init?
[2019-01-11 01:24] Steve Litt > Hi all, > > Months ago IBM bought Redhat, and IBM might not want to throw a million > a year at a dev group devoted to keeping the systemd leaky boat afloat. > Meanwhile, just today another major systemd snafu emerged. > > If IBM bails on systemd, is s6/s6-rc ready to take its place? I mean we > all know it's ready technically, and is well maintained, but is it ready > politically, with help for distro packagers? Perhaps some documentation > on best practices and making it easy to install s6/s6-rc. > > We could soon have a rare opportunity for a Linux-wide init change. I'd > hate to see systemd replaced by more snake oil. Wish it was true, and systemd got abandoned. While I am already maintaining runit as init system in Debian (and do not spare cycles for another init system), probably I could provide some assistance -- sponsor uploads, for example. But currently, s6 is quite out-of-radars in Debian.
Re: Log rotation issue with runit
[2018-12-27 20:39] Guillermo > El jue., 27 dic. 2018 a las 6:36, Dmitry Bogatov escribió: > > > > 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. > > SIGTERM should make svlogd exit cleanly, are you sure? It does for me, > and when restarted, does not create any .u file (using Gentoo's runit, > which is upstream runit plus a minor patch to the makefile). Wierd. I tried again, and failed to reproduced issue with SIGTERM this time. So seems that problem is that svlogd is killed by some other signal. It is going to be quite a long debugging session. > > /etc/runit/3 changed [not included] > > What does this mean? Is this Debian with runit as the init system and > a modified /etc/runit/3 instead of the one supplied with the Debian > package? Yes. > I'm going to make a guess here and say that the supervision tree is > not being teared down properly, resulting in svlogd processes not > exiting cleanly and producing lots of .u files, compounded with the > fact that they are never deleted during rotations because of the fix > to bug #878476... What do you mean, `supervision tree not not being teared down properly'?
Re: Log rotation issue with runit
[2018-12-27 08:07] Steve Litt > > [ 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. [...]
Re: Log rotation issue with runit
[2018-12-26 00:05] Steve Litt > part text/plain1664 > On Tue, 25 Dec 2018 13:39:17 +0000 > Dmitry Bogatov 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 > [...] > > 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. No, it is reproducible. See end of bug thread.
Re: Log rotation issue with runit
[2018-12-26 03:58] Alex Efros > 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.
Log rotation issue with runit
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
