[systemd-devel] systemd kills mdmon if it was started manually by user

[Kay Sievers]

On Wed, Nov 2, 2011 at 20:31, Williams, Dan J <dan.j.williams at intel.com> wrote:
> On Wed, Nov 2, 2011 at 11:49 AM, Kay Sievers <kay.sievers at vrfy.org> wrote:
>> On Wed, Nov 2, 2011 at 19:16, Williams, Dan J <dan.j.williams at intel.com> wrote:
>>> On Wed, Nov 2, 2011 at 7:33 AM, Kay Sievers <kay.sievers at vrfy.org> wrote:
>>>> People who like to put their rootfs on a userspace managed raid device
>>>> just get what they asked for. :)
>>>
>>> Proper care and feeding of mdmon and userspace managed block devices /
>>> filesystems is a solvable problem.  To me the ":)" runs the risk of
>>> implying we don't think we can get this right.
>>
>> It implied that I think it is totally insane what you guys try to
>> accomplish. Managing the rootfs blockdev with tools contained in the
>> rootfs itself is just crazy. No smiley this time.
>>
>
> Yes, much clearer.  Which is why the "never let mdmon run from an fs
> it is managing" is better than the current dance that was implemented
> to address the need to drop initramfs memory and get around a lack of
> having a filesystem (like /run) that persisted from early boot.  But
> we now run back into the problem of pinning initramfs memory.  Does
> systemd already expect that the full initramfs sticks around to handle
> shutdown?  If so then we have come full circle and don't really need
> the "mdmon --takeover" functionality versus just letting the
> initramfs-mdmon handle their entire lifetime of the rootfs blockdev.

It all depends on the initramfs implementation. Systemd is not
involved here and has no knowledge about what was left behind, it just
checks if there is binary in /run provided by initramfs, and then it
calls this binary instead of just bringing down the box itself.

So far only dracut implements this shutdown logic, which is just a
go-back-to initramfs and disassemble/shut down everything that was
assembled before the initramfs started the real init.

I wouldn't be surprised if we see more of these use cases from
subsystems which put their rootfs on something that needs to be
managed from userspace.

The pinned memory for the tools in initramfs that stay around in tmpfs
is probably the price to pay for these kinds of setups of the rootfs,
when subsystems want to avoid adding the needed logic to the kernel to
safely shut down the rootfs.

Kay