Control: retitle -1 runit: as init breaks several cronjobs
Hi,
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
On Sun, 19 May 2024 00:31:14 +0800 Mo Jun <royclark...@gmail.com> wrote:
> Package: runit
> Version: 2.1.2-59
> Severity: normal
>
> Dear Maintainer,
>
> Some package call invoke-rc.d for theirs functions. For example,
> anacron have
>
> [anacron and stunnel examples]
>
> On systems using runit as init, due to
> /lib/lsb/init-functions.d/40-runit, `/etc/init.d/script action' is a
> no-op by default if there is a corresponding
> native runit service. This will breaks the functions of those
> packages. For example:
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..
> 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)
>
> By the way, it is mentioned in the header of
> /lib/lsb/init-functions.d/40-runit
> that if /etc/runit/lsb.runit.forward is set, `/etc/init.d/script
> action' will be
> forwarded to sv "if /etc/sv/<service> exists and is enabled". However
> I do not see this is implemented in the current version of
> 40-runit.invoke-rc.d
it's here - but you are right, 40-runit is ugly and very complex to
read
-------------------------
case "$action" in
start|stop|restart|reload|status|try-restart|force-stop|force-reload|force-restart)
if [ -z "${forcesysv:-}" ]; then
echo "here"
[ -e "/usr/share/runit/meta/$service/installed" ] && exit 0
#dh-runit+runit-helper
[ -e "/etc/sv/$service/.meta/bin" ] && exit 0 # runit trigger-sv
[ -e "/usr/share/runit/sv.current/$service/.meta/bin" ] && exit
0 # runit trigger-sv
echo "and here"
sv "$action" "$service" || true
exit 0
-------------------
it rules out services that are integrated with runit-helper or with a
trigger in runit, otherwise they will be signaled twice each upgrade
>
> And another note. The orphan-sysvinit-scripts package have installed
> /lib/rsyslog/rsyslog-rotate which calls `invoke-rc.d rsyslog rotate'
> on non-systemd
> systems. As there is no such rotate action in sv, the rotate action
> will be forwarded to /etc/init.d/rsyslog, but that will not work if
> the native runit service of rsyslog is running. After looked into
> /etc/init.d/rsyslog, I
> `/etc/init.d/rsyslog rotate' is the same as `sv hup rsyslog' and `sv
> reload
> rsyslog'.
> Maybe assists from the Maintainer of the orphan-sysvinit-scripts
> package is needed
> to make the lograte for rsyslog functional in runit-init systems.
This is possible, but what if orphan-sysvinit-scripts is not installed?
After all in a runit-init system it's likely that one wants to use
runit services, not sysvinit scripts..
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
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
Regards,
Lorenzo
