Hey,
not sure exactly when, but probably sometime in the last 2 versions of the package, a new /etc/logrotote.d/aa-rsyslog-runit file was introduced.
logrotate cron outputs some errors since. messages :

"/etc/cron.daily/logrotate:
error: rsyslog:1 duplicate log entry for /var/log/syslog
error: rsyslog:1 duplicate log entry for /var/log/mail.log
error: rsyslog:1 duplicate log entry for /var/log/kern.log
error: rsyslog:1 duplicate log entry for /var/log/auth.log
error: rsyslog:1 duplicate log entry for /var/log/user.log
error: rsyslog:1 duplicate log entry for /var/log/cron.log
error: found error in file rsyslog, skipping
run-parts: /etc/cron.daily/logrotate exited with return code 1"

there is also /etc/logrotate.d/rsyslog with the same logs to rotate, provided by rsyslog package.

probably related to bug #1079268 and this: https://salsa.debian.org/debian/runit-services/-/commit/6d5b38ff9eb15ee838da078a12a67dc15f9d3bca (?)
maybe this check is missing in .postinst?

thanks in advance,
d.

Hi Dimitris,

I have the same problem and have for a while, too. I am currently on
0.8.1 and have runit/2.1.2-61~ from salsa next branch.

You and Lorenzo obviously understand the background to this issue
better than I would. If you have a patch I will be happy to test
it out on my systems and report back to you both with feedback!

Andrew

Hey,

Στις 11/1/25 12:44, ο/η Andrew Bower έγραψε:


background : there are 2 configuration files doing the same logs
rotation, and thus the error in logrotation cron. these 2 files are :

/etc/logrotote.d/aa-rsyslog-runit (from runit-services package)
/etc/logrotote.d/rsyslog (from rsyslog package)

one simple workaround would be to remove one of those 2 files (temp
workaround untill next package upgrade), or (preferably?) rename one of
those files to .disabled (if i understand log rotation correctly..)

or just comment out all lines in one of those files.

Hi Dimitris,

correct, it's in 0.8.0

Yes, that's the bug

not really: the idea is that, since there are two logrotate files with
the same entries, the first processed "wins" and the second is skipped.
I agree is a poor solution, but without cooperation on rsyslog side I
don't see many alternatives.

I tested again and besides the error from logrotate, I don't see a real
issue here:

(according to my testing)

* logrotate emits an error but continues to process his files, included
  those that are ordered after /etc/logrotate.d/rsyslog
  (so no log rotation is skipped due to this error, aa-rsyslog-runit
  simply replaces rsyslog)

* cron jobs are not affected by logrotate exit status, so every cron job
  after logrotate is processed (I tested with anacron on daily job)

Could you please look again and see if logrotation and/or cron jobs are
actually skipped due to this error (look at the expected action in the
filesystem)?

Best Regards,
Lorenzo

Hey Lorenzo,

Στις 11/2/25 01:32, ο/η Lorenzo έγραψε:


you're correct, apart from this annoying daily "spam" logrotate/cron
error, nothing else is affected.  also tested with daily anacron.

(but in general, i would prefer it completely "fixed" = no errors/spam 
:)  )

Hi everyone,

Three thoughts come to mind, reading this. Two of them, terrible...

(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.

The logic in the postinst script could be changed so it only does this
if it just added the logrotate file, and not if it previously had.

The other two, whacky ideas I had were:

(2) Install an 'inotifywatch' on the log files being moved by logrotated
and then perform sv hup. Yeah... that's excessive!

(3) Regularly perform 'sv hup' on rsyslogd as it is harmless to do so;
make sure to schedule it when we guess logrotate is finished. Also, this
is a terrible idea!

The irony of the level of rsyslog cooperation with non-systemd users, is
that as rsyslog usage drops off a cliff due to it no longer being
installed by default, we will become an ever greater proportion of its
users!

https://qa.debian.org/popcon.php?package=rsyslog

Hi Dimitris, hi Andrew,

On Fri, 14 Feb 2025 17:40:28 +0200 "Dimitris T." <dimitris@stinpriza.org> wrote:

thanks for confirming this :)

ok, I understand.

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 confess that I considered this already for a second or so when had to
fix #1079268, but them, hum, better not..

Another solution that I considered is to have rsyslogd log to
stdout and catch logs with svlogd, similar to socklog-run, but the
problem is that
* it requires editing rsyslog config file on the fly, so it's brittle
* users will likely be surprised to find system logs in
  /var/log/runit/rsyslogd
so I discarded that too.

Best,
Lorenzo

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!

maybe I can just watch /usr/sbin/rsyslogd to decide whether to install
our logrotate file and to disable it (if it's there and the rsyslogd
bin is removed); this way it would be possible for the user to disable
logrotate file from rsyslog package and turn off the warning.

if [ -f /usr/sbin/rsyslogd ] && [ ! -f
/etc/logrotate.d/aa-rsyslog-runit ]; then
 if [ -f /etc/logrotate.d/aa-rsyslog-runit.disabled ]; then
    mv -f /etc/logrotate.d/aa-rsyslog-runit.disabled \
           /etc/logrotate.d/aa-rsyslog-runit
 else cp /usr/share/runit-services/logrotate.d/aa-rsyslog-runit \
    /etc/logrotate.d/
 fi
fi

if [ ! -f /usr/sbin/rsyslogd ] && [ -f /etc/logrotate.d/aa-rsyslog-runit ]; then
  mv -f /etc/logrotate.d/aa-rsyslog-runit \
  /etc/logrotate.d/aa-rsyslog-runit.disabled
fi

I'm afraid I will still get duplicates of this bug as this
reaches stable, maybe I should leave this bug open.

How about biting the bullet and doing a dpkg-divert like
orphan-sysvinit-scripts does?

well, then we need to conflict[1] with orphan-sysvinit-scripts, only
for this. Since runit in part uses sysvinit scripts I prefer not to..

[1] not sure what happens with two diversions on the same file, I guess
we get the link flipping from one target to another depending on the
configure order..

Hi

I remembered this somehow wrong, o-s-s diverts the file in
/usr/lib/rsyslog while we are acting on the logrotate file
in /etc/logrotate.d/

so diverting the logrotate file is possible but there are still problems

debian policy [2] says
"Do not attempt to divert a conffile, as dpkg does not handle it well."

but also, when doing a diversion there will be a copy of the diverted
file under /etc/logrotate.d/, so it could cause the same error as in
this bug unless is suffixed as .disabled

finally rsyslog package does some handling of the file in
/etc/logrotate.d/ to rename it with .disabled suffix when the
package is removed but not purged

[2]https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html

Hey,
(sorry for a somewhat late reply.. wasn't receiving any bug updates...
tried subscribing to bug twice during last reply, but ... nada...)

i confess i didn't know rsyslog background untill now... (read relative
bug reports/salsa MR/etc.. even decade old rsyslog bugs..) i can now see
what Andrew meant....

anyway,
with all this background, and also reading the thread on init-diversity
list, i'd also be in favor in leaving situation as-is. can't suggest any
better solution..

technically, logrotate still works as expected, just outputs annoying
error (spam) message without serious implications..

and to be honest, now that i know rsyslog situation, i'll probably try
some alternative (eg. syslog-ng) and let it go...


thanks for all the help/info, sorry for the puzzling bug.... plz feel
free to close.

d.


p.s. devuan forks rsyslog package, would your salsa MR for rsyslog make
sense there? (can offer to forward MR to devuan maintainers if that
would help devuan+runit people..)

It's a bit sad really and totally unnecessary.

Probably wisest.

I think I'll start migrating, too!

Sounds like moving the discussion to a bug on the Devuan BTS would be a
good idea. My preference would be to solve this in the fork directly for
runit or any other init rather than a drop-in.

Adding Mark in CC

the fix on Devuan side could be to change one line in the logrotate file

postrotate
-	/usr/lib/rsyslog/rsyslog-rotate
+	for f in /usr/lib/rsyslog/*; do "$f" ; done
endscript

but as mentioned above, I'm not sure how I can identify a Devuan system
from the maintainerscript

Lorenzo

I have issues with the BTS too, I didn't get a mail for this bug in the
first place.. :/

Probably a good idea to look for alternatives, however this bug report
is useful, it makes me aware of the issue and it could be used to point
other users to a solution.

I'm going to change the logic for the logrotate file placement so that
it looks for the rsyslog binary (and not the rsyslog original logrotate
file): this way it should be possible for the user to rename
/etc/logrotate.d/rsyslog to /etc/logrotate.d/rsyslog.disable
to turn off the spamming messages.
It would still require that the user notice the spam, search for the
BTS (or opens a duplicate of this bug) and is the pointed to the
solution..
The title of this is a good description of the issue, so I'm leaving
open.

Thanks,
Lorenzo

(and other downstreams too) and I'm not sure how this could be possible.
Example:
*devuan could change the /lib/rsyslog code and add runit support, but I
 still need the duplicate logrotate file for Debian (in this case
 rsyslog gets HUP twice, and you still get spam in logs)

* devuan could change the logrotate file to work with fragments in
  /lib/rsyslog but I still need need the duplicate logrotate file for
  Debian (you only got spam in logs)

Overall fixing in Devuan only works if there is a reliable way to
identify a Devuan system in maintainerscript, so that I could make
the copying of the logrotate file a no-op in Devuan systems..

Lorenzo,

Thanks.

I am pretty reluctant to change Devuan's rsyslog package. It is doing the Right
Thing™: it has a working LSB initscript in the package and correctly rotates
logs.

The obvious way to identify a Devuan system is testing if the file
/etc/devuan_version exists.

HTH

Mark