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

Andrey Borzenkov arvidjaar at mail.ru
Sat Jan 22 09:55:00 PST 2011


2010/12/4 Tomasz Torcz <tomek at pipebreaker.pl>:
> On Sat, Dec 04, 2010 at 03:08:05PM +0300, Andrey Borzenkov wrote:
>> > (/etc/pam.d/system-auth), which automatically creates cgroups by login
>> > session, which in turn gets killed when the user has "completely logged out".
>> > That is why your mdadm gets terminated, too.
>>
>> Sure.
>>
>> > You can avoid that by adding create-session=0 to it, like:
>> >
>> > # grep pam_systemd /etc/pam.d/systemd-auth
>> > session     optional    pam_systemd.so create-session=0
>> >
>>
>> But I do want user session to be created; and systemd was specifically
>> extended to properly terminate user sessions on shutdown. It is just
>> that mdmon does not belong to user session at all.
>
>  Man page talks about kill-session= and kill-user= parameters, which
> may be useful to you.
>
>
>> > Which is the recommented way if you want processes (created by the "user") to
>> > live on even when this user has fully logged out.
>> >
>>
>> mdmon does not belong to user. User is not even aware that it is
>> started. And it is likely not the last case. So systemd does need some
>> framework which can move such processes out of user session. It
>> probably needs some sd_daemon API to notify systemd that it is system
>> level task even if it was started as result of user interaction.
>
>  Well, it is started by user, so it belongs to user. And
> systemd has an API to start system-level task as a result of
> user interaction: it is called "systemctl start mdmon.service".
>

mdmon is not a singleton - it is started for every array that needs it
(not each array needs it). Can you pass extra parameters that identify
object mdmon should monitor via systemctl?

Using udev to listen to new array event and starting mdmon from there
looks promising. I do not know whether it is possible to identify such
arrays at this point though nor do I have hardware to test.


More information about the systemd-devel mailing list