On Tue, Feb 18, 2025 at 02:45:04PM +0100, lorenzo wrote:
> On Fri, 14 Feb 2025 17:40:28 +0200 "Dimitris T."
> <[email protected]> wrote:
>
> > if i set /etc/logrotate.d/rsyslog -> rsyslog.disabled (so only one
> > logrotation script for rsyslog ), then logrotate completes
> > succesfully. but...
> >
> > when some runit-services trigger is run following some package
> > upgrade (eg. rsyslog), then, aa-rsyslog-runit is also renamed to
> > aa-rsyslog-runit.disabled.. (?!) and there is no (rsys)log rotation!!
>
> On Fri, 14 Feb 2025 19:03:48 +0000 Andrew Bower <[email protected]> wrote:
>
> >
> > (1) Ah, looking at d/runit-services.postinst, that looks fixable.
> > runit-services is trying to make sure that if it adds this file and
> > rsyslog's rotation is already disabled, then the new file should be
> > installed as disabled, too.
>
> from coding point of view this is fixable, the issue is more on the
> social and policy side. in short, we risk to be forced to revert due to
> an escalation from rsyslogd maintainer..
> well, there is no reply in #1079270 so as long as it doesn't break usage
> under systemd maybe he doesn't care.
>
> I'll see what I can do..
I think *a* change would be ok - currently you make the runit state
identical to the non-runit state regardless. If you only do that at the
point that you first add the file, you are honouring the user's
preference.
So:
if not (runit.enabled or runit.disabled) then {
if standard.disabled
install runit script as disabled
else if standard.enabled
install runit script as enabled
}
However, this only solves this original problem in the case where the
user has deliberately disabled the standard script to suppress the
warnings. Users who just install things get the warnings. I would agree
that there is no obvious solution within the runit package to this that
wouldn't be problematic from a social/policy point of view or
disproportionately complicated from a technical point of view.
The logical place to fix this is in the rsyslogd package.
Perhaps we should team up with sysv people to solve this in a
sustainable way. I wonder if we should contribute some functionality to
logrotate to allow augmenting configs. This could potentially be framed
as support for read-only usr type modes. But I'm probably guilty of
looking for a technical solution to a political problem here!
