Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi Mark, On 6/18/23 10:33, Mark Hindley wrote: > I would still disagree with that. just to avoid misunderstandings, my current understanding is: 1) technical issue: non-bootable systems on some non-systemd systems - can be handled by moving mdadm initscripts into orphan-sysvinit-scripts, and - adding a note in mdadm to point to orphan-sysvinit-scripts. 2) technical issue: no maintenance tasks on non-systemd systems - could be handled by a future orphan-cron-jobs package - is an issue that needs to be adressed for sure, but isn't critical like booting. 3) non-technical issue: systemd vs. sysvinit - we have decided that in Debian. Is my understanding correct, that: * we have an agreement on the 1) being technically possible to be solved that way * we still need to find a solution in place for 2) * we agree to disagree on 3) If so, do you mind taking care about mdadm initscript making its way into orphan-sysvinit-scripts? Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Daniel, Many thanks. On Sun, Jun 18, 2023 at 07:48:03AM +0200, Daniel Baumann wrote: > Assuming there are no problems of having mdadm initscripts in > orphan-sysvinit-scripts, I think this is the best way forward. I would still disagree with that. However, even if that were the path taken, it doesn't restore the mdadm cron snippets. This isn't just about the initscripts, it is support for non-systemd systems in a more general sense. Best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi Mark, On 6/17/23 19:13, Mark Hindley wrote: > I am asking gently for the reinstatement of the recently removed non-systemd > initscripts. I hear you, but I prefer not doing this for the stated reasons. How about getting the mdadm initscript into orphan-sysvinit-scripts? I read the section about bugs/limitations on orphan-sysvinit-scripts but can't see anything that would be of concern for mdadm. Assuming there are no problems of having mdadm initscripts in orphan-sysvinit-scripts, I think this is the best way forward. Also, I've added a check to show a note via debconf (only briefly tested): https://git.progress-linux.org/users/daniel.baumann/debian/packages/mdadm/log/ Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Michael, On Sat, Jun 17, 2023 at 07:17:40PM +0300, Michael Tokarev wrote: > You're still not getting the point. Which is the lack of real infrastructure > within other init systems, which needs real work. Which, apparently, > neither you nor other complainers are willing to do. I am not complaining. I am asking gently for the reinstatement of the recently removed non-systemd initscripts. Together with an offer to provide continued and on-going support for them. However imperfect those scripts may have been, they worked, were used and were useful and would continue to be so. With best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
17.06.2023 19:05, Mark Hindley wrote: Michael, On Sat, Jun 17, 2023 at 08:07:52AM +0300, Michael Tokarev wrote: I wonder do we want no mdadm in debian at all or working mdadm with systemd? From the two alternatives I definitely prefer the working one.. That isn't the choice on offer. It is. The suggestion was to raise this bug report severity level to prevent mdadm from migrating to testing and later on to be removed from Debian. Without offering real implementation for whatever init systems you use, which, as the maintainer explained, is not an easy task to support and he lacks resources to do so. Raising bug severity like that without actually doing some real stuff gains nothing besides making mdadm to be removed. And with my former mdadm maintainer hat on, I agree completely the way it worked with sysvinit was a complete mess, systemd bought up the missing-for-years infrastructure needed for it to work well, finally. You're still not getting the point. Which is the lack of real infrastructure within other init systems, which needs real work. Which, apparently, neither you nor other complainers are willing to do. So please don't remove mdadm from debian. Thanks, /mjt
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Michael, On Sat, Jun 17, 2023 at 08:07:52AM +0300, Michael Tokarev wrote: > I wonder do we want no mdadm in debian at all or working mdadm with systemd? > From the two alternatives I definitely prefer the working one.. That isn't the choice on offer. The choice is mdadm in Debian which is only usable with systemd or mdadm in Debian which is usable with systemd, openrc, runit and sysvinit. Best wishes Mark
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
17.06.2023 06:30, Olaf Meeuwissen wrote: .. Please consider bumping this bug to a Severity that keeps it from migrating to testing/trixie until this is resolved. # I'll be putting mdadm on hold on my systems for the time being. I wonder do we want no mdadm in debian at all or working mdadm with systemd? From the two alternatives I definitely prefer the working one.. /mjt
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi, Thanks for forwarding this, Mark. Daniel, I'm not particularly charmed by the retitling to show note about missing boot integration for non-systemd I have a few runit-init based systems with mdadm that run testing, which, thankfully, still has 4.2-5. The version in sid is old enough to migrate to testing but is still waiting on autopkgtest results before it migrates. Other than that there is nothing that prevents 4.2+20230508-2 from migrating and hit unsuspecting mdadm users *without* any message at all. These users will not be able to reboot their system after upgrading. Just image the pain of having this happen to a system in a remote location. Please consider bumping this bug to a Severity that keeps it from migrating to testing/trixie until this is resolved. # I'll be putting mdadm on hold on my systems for the time being. Thanks in advance, -- Olaf Meeuwissen
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Daniel, Many thanks for your reply. On Tue, Jun 13, 2023 at 03:32:23PM +0200, Daniel Baumann wrote: > > It would be a great help to users of non-systemd inits if you could restore > > them. > > thanks you for your report. > > Personally I'm using systemd, but in general I fully agree that as long > as it's no "burden" to keep the sysvinit scripts around, I'd keep them. > > For mdadm specifically, using sysvinit scripts has been the source of a > bunch of bugs as some things are not properly supportable when it comes > to events/race-condition handling when detecting raid devices in early boot. Could you be a little more specific as to what insurmountable issues still persist? > Most other distributions as well as upstream don't support sysvinit > anymore in mdadm. I have spent some time looking through the source and upstream documentation. I can't find any mention that upstream supports only systemd. Can you point me to it? > I can see at least three disadvantages for keeping > sysvinit scripts in mdadm around: > > * I would need to support them in Debian for a type of system I > don't use anywhere anymore since several Debian releases. > Personally, I'd rather spend time on, to me, more appealing things. > > * Keeping sysvinit support for mdadm in Debian de-facto makes me > upstream for these scripts, which doesn't seem right given that > I don't use it myself. I don't think I was asking you to do either of these. I was merely asking for reinstatement of the existing scripts (which work) and accept and merge reasonable and tested patches in the future. That seems a pretty small burden. > * Keeping sysvinit support would "falsly advertise" that it's actually > maintained and cared for, which isn't the case and I'd expect that > a lot of bugs don't get spottet in time for a next Debian release. I am sure people who use mdadm with non-systemd init *do* care about it and will be happy to identify and correct any issues. > A solution could be for those that like to keep using sysvinit, to > submit the scripts for inclusion in the orphan-sysvinit-scripts package > and maintain it there. Notwithstanding Matthew's great work in orphan-sysvinit-scripts, this is a suboptimal solution. * The approach has inherent problems that are well documented[1] * If there *are* issues with mdadm running without systemd as PID1, this approach wouldn't solve or avoid them I hope you will reconsider. With thanks and best wishes Mark [1] https://salsa.debian.org/matthew/orphan-sysvinit-scripts/-/blob/master/README.org
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
retitle 1037496 show note about missing boot integration for non-systemd thanks Hi Mark, On 6/13/23 14:28, Mark Hindley wrote: > It would be a great help to users of non-systemd inits if you could restore > them. thanks you for your report. Personally I'm using systemd, but in general I fully agree that as long as it's no "burden" to keep the sysvinit scripts around, I'd keep them. For mdadm specifically, using sysvinit scripts has been the source of a bunch of bugs as some things are not properly supportable when it comes to events/race-condition handling when detecting raid devices in early boot. Most other distributions as well as upstream don't support sysvinit anymore in mdadm. I can see at least three disadvantages for keeping sysvinit scripts in mdadm around: * I would need to support them in Debian for a type of system I don't use anywhere anymore since several Debian releases. Personally, I'd rather spend time on, to me, more appealing things. * Keeping sysvinit support for mdadm in Debian de-facto makes me upstream for these scripts, which doesn't seem right given that I don't use it myself. * Keeping sysvinit support would "falsly advertise" that it's actually maintained and cared for, which isn't the case and I'd expect that a lot of bugs don't get spottet in time for a next Debian release. As of policy 4.5.0, including sysvinit scripts in a package if systemd units are present, is not longer recommended but optional, so that (at least after the bookworm release last weekend) I'd expect that a lot of other packages are going to drop the sysvinit scripts too. A solution could be for those that like to keep using sysvinit, to submit the scripts for inclusion in the orphan-sysvinit-scripts package and maintain it there. > Installing recent mdadm on a non-systemd system can render the system > unbootable. Good point, I'll think about emitting an appropriate message so that it's not easily overseen in such situtations. Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Source: mdadm Version: 4.2+20230227-1 Severity: normal Dear Daniel, SysV initscripts and cron jobs have recently been removed from mdadm. It would be a great help to users of non-systemd inits if you could restore them. Service files and initscripts can happily coexist and systemd will use the available service files in preference. Installing recent mdadm on a non-systemd system can render the system unbootable. Thanks for you consideration. Mark -- System Information: Debian Release: 12.0 merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
