Hi, sorry for delayed reply.
I'm tracking the rsyslogd rotation issue separately https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079268 there are several ideas there, first one is to ask the rsyslog maintainer to cooperate (not sure it will happen) https://salsa.debian.org/debian/rsyslog/-/merge_requests/10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079270 On Wed, 22 May 2024 16:57:33 +0800 Mo Jun <royclark...@gmail.com> wrote: > Followup-For: Bug #1071395 > Package: runit > > Hi, > > [...] > I am curious about that is there major problems if a service being > signaled twice on each upgrade? If no, I think it may be a good > compromise that if /etc/runit/lsb.runit.forward is set, standard > actions will be forwarded to runit services unconditionally even if > they are integrated with runit-helper or with a trigger in runit, as > being signaled twice on upgrade is better than doing nothing during > normal operations. Still nonstandard actions need special > treatments. Obviously it is left to the user/sysadmin to decide > whether set /etc/runit/lsb.runit.forward or not. As it needs > time/effort to fix all related packages, I wish have this compromise, > so that I can have a more functional system. for the general issue, I'm thinking of changing the way the override/forward works: it seems that there are too many (even conflicting) use cases where people ask for some variation that will fit a specific use case but not others. One thing could be to move the override script into /etc/runit/ so that users customizations will persist on package upgrade. Another thing is to simplify the mechanism, possibly in a way that the override can be automated in runscripts. I need to find some additional time to test if my idea works, than I will make a proposal to check if it satisfy your needs. Best Regards, Lorenzo
