On Tue, Jan 25, 2011 at 7:28 AM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Tue, 25.01.11 06:58, Andrey Borzenkov (arvidj...@mail.ru) wrote:
>
>> > systemd supports instantiated services, for example to deal with the
>> > gettys (e.g. "getty@tty5.service"). It should be trivial to use the same
>> > for mdmon (e.g. "mdmon@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@.service") and then instantiate it when needed with "systemctl
> start mdmon@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@.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@localhost ~]# systemctl status mdmon@md127.service
mdmon@md127.service - mdmon service
Loaded: loaded (/etc/systemd/system/mdmon@.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@.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",... )?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
