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