Followup-For: Bug #1071395
Package: runit
Hi,
On Mon, 20 May 2024 15:35:03 +0200 Lorenzo <plore...@disroot.org> wrote:
> thanks for your detailed report:
> the problem that you describe is real, but there is no easy/ catch-all
> solution. Keep in mind that a certain number of maintainers are removing
> cronjobs in favor of systemd timers
Thanks for your quick reply.
Please mind that this issue is not restrict to cronjobs; some packages
call invoke-rc.d/sysvinit scripts elsewhere, not restrict to cronjobs.
And yes, I have noticed some(many?) Maintainers are shifting to support
systemd-only things.
I have done searches using `sudo grep -rl "invoke-rc\.d"' and
`sudo grep -rl "/etc/init\.d/"' in /etc/ on my system running Debian sid.
After a quick look, here are scripts I found calling invoke-rc.d directly:
/etc/cron.d/anacron
/etc/dhcp/dhclient-exit-hooks.d/ntpsec
/etc/init.d/selinux-autorelabel
/etc/logrotate.d/apache2
/etc/logrotate.d/cups-daemon
/etc/logrotate.d/tor
/etc/network/if-up.d/ntpsec-ntpdate
/etc/ppp/ip-up.d/0stunnel4
/etc/ppp/ip-down.d/0stunnel4
Here are those calling /etc/init.d/script directly:
/etc/bash_completion.d/openvpn
/etc/inittab
/etc/logrotate.d/stunnel4
/etc/network/if-down.d/openvpn
/etc/network/if-up.d/mountnfs
/etc/network/if-up.d/openvpn
/etc/ppp/ip-up.d/0000usepeerdns
/etc/ppp/ip-down.d/0000usepeerdns
There are many matches for `sudo grep -rl "/etc/init\.d/"' under
/etc/init.d/, but I do not have a look for all of them. And /etc/init.d/
is also mentioned in /etc/needrestart/hook.d/{10-dpkg,90-none} which are
perl scripts, as I do not know about perl, I can not figure out them
actually call /etc/init.d/script or not.
Most aforementioned scripts calling invoke-rc.d/sysvinit scripts directly
use standard start/stop/reload... actions. Exceptions include:
/etc/bash_completion.d/openvpn calls /etc/init.d/openvpn without args.
/etc/logrotate.d/stunnel4 calls `/etc/init.d/stunnel4 reopen-logs'
/etc/inittab calls `/etc/init.d/powerfail now'
(although there is no /etc/init.d/powerfail on my system)
As shown in /lib/rsyslog/rsyslog-rotate, some packages may call
invoke-rc.d or /etc/init.d/script directly outside /etc, and it is even
possible that some packages call them in binary executables.
So I think it may be a little difficult to find all those packages.
> it breaks some cronjobs, hopefully not all. For some just using the
> initscript nonstandard action, like 'reopen-logs' or 'rotate', may work.
> I don't have any estimate, maybe 90% work, maybe 90% are broken..
For the "rotate" action of rsyslog, forward it to initscript will not
work, as it needs a pid file which is no available when running
runit service. And the "reopen-logs" action of stunnel4 also needs
a pid file. I think it needs to examine each initscript to find out
whether forwarding a nonstandard action will work or not, making
having an estimate a little difficult.
> > Maybe `invoke-rc.d script action' and `/etc/init.d/script action'
> > should be forwarded to the corresponding native runit service to fix
> > this bug.
>
> how many cases there are, apart from anacron? If it's only anacron, I
> think is better to fix the cronjob rather than signalling each service
> twice (see below)
I agree that the optimal is to fix the cronjob and other things by
changing them to call runit services.
> it rules out services that are integrated with runit-helper or with a
> trigger in runit, otherwise they will be signaled twice each upgrade
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.
> This is possible, but what if orphan-sysvinit-scripts is not installed?
I have not test yet, but it seems to me that if orphan-sysvinit-scripts
is not installed, rsyslog will not receive SIGHUP after logrotate.
The rsyslog package ships with /etc/logrotate.d/rsyslog, which calls
/lib/rsyslog/rsyslog-rotate.(orphan-sysvinit-scripts ships its own
version of this file and diverted the original file to
/usr/lib/rsyslog/rsyslog-rotate.real)
The original /lib/rsyslog/rsyslog-rotate will do nothing on
non-systemd systems:
#!/bin/sh
if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
fi
> After all in a runit-init system it's likely that one wants to use
> runit services, not sysvinit scripts..
Agreed. Now I think it is easier to make the lograte for rsyslog
functional to just change /lib/rsyslog/rsyslog-rotate in
/etc/logrotate.d/rsyslog to something else which will call
`sv hup rsyslog' on runit-init systems. (But again, I think find all
issues and fix them like this will needs some time/effort.)
> Option to deal with this cronjob issue are (add if you have others):
>
> * add runit code in cronjobs (for example for this would work well for
> anacron)
>
> * runit-services could start to ship cronjobs for it's services, when
> the cronjob is missing or it doesn't work with the runit service
> (for example, rsyslogd)
>
> * we could stop using cronjobs and use have runit-timers, converted from
> systemd timers (I don't like this option - I don't see the
> advantage of having N active timers instaed of one service that does N
> jobs - but it's feasible with 'snooze' and a converter)
>
> * a mix of the above
I think adding runit code is the best, but I guess these will need
cooperation from the Maintainer of other packages?
> Before deciding I would like to gather some data to make an informed
> choice, for example
> How many cronjobs are gone in favor of timers(compared with olstable)?
> How many cronjobs calls standard sysv actions (like anacron)?
> How many calls non-standard actions, and how many of these fails under
> runit?
>
> I didn't have the time to gather data so far, so I'm holding this
> decision; if you have any data please share
I will try to gather more data on these and send them to here.
Regards,
Jun MO
