Hi, (Dropping mdadm upstream, as this is not an upstream problem)
On 31 Mar 2016 19:53, "Dimitri John Ledkov" <x...@debian.org> wrote: > > On 31 March 2016 at 20:12, Jes Sorensen <jes.soren...@redhat.com> wrote: > > Felipe Sateler <fsate...@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 <fsate...@debian.org> wrote: > >>> > >>> On Sat, 22 Aug 2015 22:32:00 -0300 fsate...@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
