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

[Andrey Borzenkov]

On Tue, Jan 25, 2011 at 7:28 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 25.01.11 06:58, Andrey Borzenkov (arvidjaar at mail.ru) wrote:
>
>> > systemd supports instantiated services, for example to deal with the
>> > gettys (e.g. "getty at tty5.service"). It should be trivial to use the same
>> > for mdmon (e.g. "mdmon at md3.service").
>> >
>> That's right, but the names are not known in advance and can change
>> between reboots. This means such units have to be generated
>> dynamically, exist until reboot (ramfs?) and be removed when array is
>> destroyed. Not sure it is really manageable.
>
> Hmm? It should be sufficient to just write the service template properly
> ("mdmon at .service") and then instantiate it when needed with "systemctl
> start mdmon at xyz.service" or something equivalent. itMs a matter of
> issuing a single dbus call.
>
>> And which instance should generate them? mdadm?
>
> i think it is much nicer to spawn the necessary mdadm service instance
> from a udev rule,

Yes, this can be done relatively easily; as proof of concept:

SUBSYSTEM!="block", GOTO="systemd_md_end"
ACTION!="change", GOTO="systemd_md_end"
KERNEL!="md*", GOTO="systemd_md_end"
ATTR{md/metadata_version}=="external:[A-Za-z]*", RUN+="/bin/systemctl
start mdmon@%k.service"
LABEL="systemd_md_end"

where mdon at .service is


[Unit]
Description=mdmon service
BindTo=dev-%i.device
After=dev-%i.device

[Service]
Type=forking
PIDFile=/dev/.mdadm/%i.pid
ExecStart=/sbin/mdmon --takeover %i


With the result

[root at localhost ~]# systemctl status mdmon at md127.service
mdmon at md127.service - mdmon service
          Loaded: loaded (/etc/systemd/system/mdmon at .service)
          Active: active (running) since Tue, 08 Feb 2011 09:43:30
-0500; 5min ago
         Process: 1467 ExecStart=/sbin/mdmon --takeover %i
(code=exited, status=0/SUCCESS)
        Main PID: 1468 (mdmon)
          CGroup: name=systemd:/system/mdmon at .service/md127
                  └ 1468 /sbin/mdmon --takeover md127

Setting SYSTEMD_WANTS would be more elegant solution, but it does not
work with current systemd implementation. It is capable of starting
requested units only on "add" event (effectively the very first time
device becomes plugged), while mdmon must be started on "change"
event, as only then we know whether mdmon is required at all.

Running mdmon via systemd in this way opens up interesting
possibility. E.g. service could be declared "immortal" and be exempt
from usual shutdown sequence ... or is it possible to do already?

Actually it can be implemented even without mdadm patches; apparently
it is possible to suppress normal starting of mdmon by setting
MDADM_NO_MDMON=1

>                           but you could even run it from mdadm by invoking one
> dbus call from it.
>

It may turn out to be necessary still. If container needs mdmon,
arrays it contains won't become read-write until mdmon is started. If
mdmon is started asynchronously by udev, there is window where someone
may try to use array before it is rw. As trivial example, mount unit
which depends on md device unit.

I do not think mdadm maintainer will be happy to add D-Bus dependency
to something that is likely to be included in initrd though :) But may
be we could simply try execl("/bin/systemctl", "start", ...) before
current execl("/sbin/mdmon",... )?