Bug#796624: mdadm: Has init script in runlevel S but no matching service file

[Felipe Sateler]

Hi,

(Dropping mdadm upstream, as this is not an upstream problem)

On 31 Mar 2016 19:53, "Dimitri John Ledkov" <xnox at debian.org> wrote:
>
> On 31 March 2016 at 20:12, Jes Sorensen <Jes.Sorensen at redhat.com> wrote:
> > Felipe Sateler <fsateler at debian.org> writes:
> >> Hello upstream mdadm.
> >>
> >> I'm adding you to CC to resolve the issue of an init script that
> >> current debian uses, that might possibly be redundant. Please see my
> >> below diagnosis
> >>
> >> On 24 December 2015 at 16:10, Felipe Sateler <fsateler at debian.org> wrote:
> >>>
> >>> On Sat, 22 Aug 2015 22:32:00 -0300 fsateler at debian.org wrote:
> >>> > Hi,
> >>> >
> >>> > Your package mdadm has an initscript that is enabled in runlevel S,
> >>> > but it does not provide a corresponding systemd service unit.
> >>>
> >>> It seems that the mdadm-raid init script (which triggered this bug
> >>> report) is not useful on a udev system (which all systemd systems
> >>> are[1]). The file /lib/udev/rules.d/64-md-raid-assembly.rules assembles
> >>> the arrays incrementally as devices are known to udev, and so running
> >>> a separate assembly step should be superfluous. If this is not true,
> >>> then maybe this should be reported upstream, as there is a systemd
> >>> service missing.
> >>
> >> For reference, the init script in question can be seen in the souces
> >> site[1]. On boot, it invokes mdadm --assemble and reports some status
> >> messages for each md device.
> >>
> >> So, the questions are: is this init script redundant on a udev system?
> >> If not, isn't an equivalent systemd unit missing upstream?
> >
> > I haven't looked at Debian's scripts here, but whatever Debian uses as
> > init scripts to control mdadm startup is decided by the Debian mdadm
> > maintainer. We do carry a set of system files for mdadm in the
> > mdadm/systemd directory, so if something is missing, it may be that the
> > Debian maintainer forgot to include it.
> >
>
> In Debian we have multiple configuration that we support:
> * initramfs-tools based initrd without udev

Is this really supported? On jessie and sid, both initramfs-tools and
dracut depend on udev. tinyinitramfs doesn't, but I don't think people
expect to mount mdadm arrays from tinyinitramfs.

> * initramfs-tools based initrd with udev
> * regular userspace with systemd

This implies udev. Systemd without udev is bound to not-work.

> * regular userspace without systemd (sysv init based, with udev)

So, except for the first (which I doubt is actually supported), all
use cases require udev.

>
> I believe some of the initscripts are specific to second & last cases,
> and indeed quite debian (and debian derivatives) specific rather than
> upstream worthy.

If for the second case, then we need a wrapper systemd unit. If for
the last, we need to mask the unit so that systemd does not run it.

> In the udev present and systemd available cases packaging is (or
> should be trying to anyway) to follow upstream set of units/udev
> rules.

AFAICS, it mostly does, except it disables incremental array assembly
(see bug #784070). Which I think makes the mdadm-raid initscript
necessary again (otherwise nothing assembles the arrays!). But I
declare myself mostly ignorant WRT mdadm.


> But due to supporting the two extra cases listed above we have
> initscripts without equivalent systemd unit, whichi imho should be
> just fine.

The only problem is that the init script in question is run in
runlevel S. Upstream systemd support for runlevel S in the sysv
generator was removed a long time ago, and is kept as a debian patch
to systemd. The goal is to remove this support for stretch, but for
that we need to provide equivalent systemd units for all affected
packages (mdadm being one of the most important left).

Note that a simple native unit wrapping the init script is sufficient
as well. All that we want to do is make runlevel S scripts disappear
from the view of the sysv generator.

> If there is a problem with that, I don't see a reason to
> report it to mdadm upstream / linux-raid mailing list...

Right, sorry about that. I did not realize debian had disabled
incremental array assembly[1], and thus the script is necessary
AFAICT. I involved upstream only because I thought the script was
either redundant or missing upstream, and was looking for
confirmation. The final goal for me was being able to propose a patch
(either mask, as already done with other init scripts, or add a native
systemd unit wrapping the init script).

>
> Apart from aesthetics, is there an actual problem with shipping extra
> initscripts on debian?

Only if they run on runlevel S.


[1] BTW, your 3.4 upload is not on the mdadm git, which is why I did
not spot the udev rule modification (yes, I should have looked at the
archive contents as well...).

Saludos