Hi

On Thu, 27 Feb 2025 23:12:24 +0100 lorenzo <plorenzo@disroot.org> wrote:

On Thu, 27 Feb 2025 21:17:18 +0000
Andrew Bower <andrew@bower.uk> wrote:

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

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 05, 2025 at 06:53:34PM +0200, Dimitris T. wrote:

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

It's a bit sad really and totally unnecessary.

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

Probably wisest.

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

I think I'll start migrating, too!

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adding Mark in CC

On Thu, 6 Mar 2025 11:37:00 +0100
Lorenzo <plorenzo@disroot.org> wrote:

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

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.

Yeah but this pacakge has to work properly both in Debian and Devuan
(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..

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 5 Mar 2025 18:53:34 +0200
"Dimitris T." <dimitris@stinpriza.org> wrote:

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

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

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.

Yeah but this pacakge has to work properly both in Debian and Devuan
(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..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

On Thu, Mar 06, 2025 at 12:05:05PM +0100, Lorenzo wrote:

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

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

HTH

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)