Hey Lorenzo,
Στις 11/2/25 01:32, ο/η Lorenzo έγραψε:
this:
https://salsa.debian.org/debian/runit-services/-/commit/6d5b38ff9eb15ee838da078a12a67dc15f9d3bca
(?) maybe this check is missing in .postinst?
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)?
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
:) )
--
something relative i noticed.
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!!
to reproduce :
===
$ doas mv /etc/logrotate.d/rsyslog /etc/logrotate.d/rsyslog.disabled
$ ls -la /etc/logrotate.d :
-rw-r--r-- 1 root root 260 Dec 26 13:53 aa-rsyslog-runit
-rw-r--r-- 1 root root 248 Feb 23 2023 rsyslog.disabled
$ doas apt install --reinstall rsyslog
...
Processing triggers for runit (2.1.2-61) ...
ok: run: rsyslog: (pid 31634) 0s
Processing triggers for orphan-sysvinit-scripts (0.17) ...
Processing triggers for runit-services (0.8.2) ...
$ ls -la /etc/logrotate.d :
-rw-r--r-- 1 root root 260 Dec 26 13:53 aa-rsyslog-runit.disabled
-rw-r--r-- 1 root root 248 Feb 23 2023 rsyslog.disabled
===
that's another issue which can be triggered because of the error
output.. = maybe someone, trying to fix/silence error messages, break
logrotate functionality completely.. which could be serious in some
cases...
--
i'm not sure what a clean solution would be... maybe renaming rsyslog -
> .disabled and keeping aa-rsyslog-runit, might be cleaner when
runit-services is used?
and if/when cooperation with rsyslog is restored (...?) then it could be
easily reverted... (i think).
thanks!
d.
