[systemd-devel] systemd kills mdmon if it was started manually by user
Lennart Poettering
lennart at poettering.net
Wed Nov 2 16:35:56 PDT 2011
On Wed, 02.11.11 10:21, Williams, Dan J (dan.j.williams at intel.com) wrote:
> > That means we'd:
> >
> > a) patch systemd to check whether argv[0][0] of a process is '@' and
> > owned by root and exclude it from killing on shutdown.
> >
> > b) patch mdmon to set argv[0][0] of itself to '@' iff it is running from
> > the initrd. If it is run from the main system it should not set that and
> > just be shut down like any other service.
>
> Well, there are two cases to consider:
>
> 1/ user starts the array manually and stops it with mdadm -Ss (mdmon
> automatically shuts down). No need for a service mdmon just follows
> the lifespan of the array.
>
> 2/ user starts the array but then expects it to be around until system shutdown
>
> In the latter case let the initramfs-mdmon takeover all arrays with
> "mdmon --takeover --all". But if all arrays may eventually be
> re-parented to an mdmon instance from /run, why not always start mdmon
> from there?
Well I am not sure how mdmon works, but let's say you booted up with an
initrd lacking mdmon. Then, while the machine is up you set up a some md
device, and start mdmon for that. At this point it will be independent
of the initrd. But that should be OK since at shutdown time it can be
detached cleanly without any special magic, too, since mdmon is not
stored on that md device. So if you boot from md you need mdmon in the
initrd. If you just use md outside of the root disk, then running mdmon
as a normal service (i.e. one that is shut down like any other) should
be perfectly fine.
This why I suggested that only mdmon run from the initrd should set
argv[0][0] = '@', because only that one needs the special handling that
it cannot be terminated properly on shut down. The one running from the
normal system can be treated like a standard systemd service.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list