Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1197859 > unrolled thread

Bug#1071395: runit: breaks the functions of some packages with runit as init

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1071395: runit: breaks the functions of some packages with runit as init Mo Jun <royclark086@gmail.com> - 2024-05-18 18:40 +0200
    Bug#1071395: runit: breaks the functions of some packages with runit as init Lorenzo <plorenzo@disroot.org> - 2024-05-20 15:40 +0200
    Bug#1071395: runit: as init breaks several cronjobs Mo Jun <royclark086@gmail.com> - 2024-05-22 11:10 +0200

#1197859 — Bug#1071395: runit: breaks the functions of some packages with runit as init

[Multipart message — attachments visible in raw view] — view raw

Package: runit
Version: 2.1.2-59
Severity: normal

Dear Maintainer,

Some package call invoke-rc.d for theirs functions. For example, anacron
have
installed /etc/cron.d/anacron which uses `/usr/sbin/invoke-rc.d anacron
start'
on non-systemd systems. And on non-systemd systems, `invoke-rc.d script
action'
is translated to `/etc/init.d/script action'. For example:

$ sudo sh -x /usr/sbin/invoke-rc.d anacron start
# skipped many lines
+ /etc/init.d/anacron start
+ exit 0

Some package actually call `/etc/init.d/script action' directly. For
example,
stunnel4 have installed /etc/logrotate.d/stunnel4 which calls
`/etc/init.d/stunnel4 reopen-logs'. (Although there is no native runit
service
for stunnel4 in Debian currently.)

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:

$ sudo sh -x /etc/init.d/anacron start
# skipped many lines
+ [ ! -e /etc/runit/lsb.runit.mask ]
+ [ -d /etc/sv/anacron ]
+ [ -d /usr/share/runit/sv.current/anacron ]
+ [ -h /etc/service/anacron ]
+ [ -z  ]
+ [ -e /usr/share/runit/meta/anacron/installed ]
+ [ -e /etc/sv/anacron/.meta/bin ]
+ [ -e /usr/share/runit/sv.current/anacron/.meta/bin ]
+ exit 0

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.

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

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
find that
`/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.

Regards,
Jun MO

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit depends on:
ii  libc6           2.38-11
ii  runit-helper    2.16.2
ii  sysuser-helper  1.3.9+really1.4.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-59

Versions of packages runit suggests:
ii  runit-services  0.7.2
pn  socklog         <none>
pn  ucspi-unix      <none>
ii  zsh             5.9-6+b1

-- Configuration Files:
/etc/runit/1 changed [not included]
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

[toc] | [next] | [standalone]

#1198054

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 <royclark086@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

[toc] | [prev] | [next] | [standalone]

#1198230 — Bug#1071395: runit: as init breaks several cronjobs

[Multipart message — attachments visible in raw view] — view raw

Followup-For: Bug #1071395
Package: runit

Hi,

On Mon, 20 May 2024 15:35:03 +0200 Lorenzo <plorenzo@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web