Bug#916230: Log rotation issue with runit
control: tags -1 +moreinfo +unreproducible [2018-12-31 11:20] Lorenz > Hi, sorry for the late response. > > > Can you reproduce this issue with regular usage of runit > > Unfortunately I am not able to reproduce systematically. I'm still trying to > understand what causes the creation of those .u files ( i don't do kill on > runsv), > but this is not easy and also will not be quick. > I read the discussion on Supervision mailing list, I understand the > rationale behind the creation of those .u files and i'm fine with it. > I'm available to provide more details on Supervision list, if there is some > interest to dig this issue there, otherwise i will try by myself. > Feel free to put on hold or close this bug, i will reopen if I can > find a exact sequence to reproduce with regular use. Let it hang around for a while. I usually close bugs in 6-12 month, if there is nobody, who can reproduce them.
Bug#916230: Log rotation issue with runit
Dmitry Bogatov: 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. What you need are manuals that tell you about this mechanism. (-: * http://jdebp.eu./Softwares/nosh/guide/cyclog.html#COMPATIBILITY * http://skarnet.org./software/s6/s6-log.html#Logdirs * http://jdebp.eu./Softwares/djbwares/guide/multilog.html#ROTATION * http://smarden.org/runit/svlogd.8.html#sect4
Bug#916230: Log rotation issue with runit
Dear submitter, please read thread above with rationale for exsting behaviour. Existence of those .u files means that svlogd was terminated in non-graceful way. For example, I can confirm, that killing `svlog' process with SIGKILL results in .u file leak. Personally, I accumulated number of .u files while I was debugging my runscripts. Can you reproduce this issue with regular usage of runit -- I mean no processs kill(2)ing, only boot, halt, reboot, /etc/service symlinks and sv(8) tool. If not, it is still unfortunate, that this behaviour is undocumented and creates files with confusing names. Probably, this issue could be somewhat alleviated by choosing another suffix (f, for `fail', maybe) and documenting this behaviour.
