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

[Andrey Borzenkov]

On Sat, Dec 4, 2010 at 12:12 PM, Christian Parpart <trapni at gentoo.org> wrote:
> On Saturday, December 04, 2010 09:41:26 am Andrey Borzenkov wrote:
>> If user starts array manually (mdadm -A -s as example) from within
>> user session and array needs mdmon, mdmon becomes part of user session
>> control group:
>>
>> ├ user
>> │ └ root
>> │   └ 1
>> │     ├ 1916 login -- root
>> │     ├ 1930 -bash
>> │     ├ 1964 gpg-agent --keep-display --daemon --write-env-file
>> /root/.gnup... │     └ 2062 mdmon md127
>>
>>
>> It is then killed by systemd during shutdown as part of user session.
>> It results in dirty array on next boot.
>>
>> Is there any magic that allows daemon to be exempted from killing?
>
> While your raid should absolutely not be corrupted on next reboot
> when mdmon receives a SIGTERM,

This won't be corrupted but it will initiate rebuilt. I have reports
that such rebuild may take hours, costing performance and loss of
redundancy.

>                                                       I suspect you're using pam_systemd.so

Yes

> (/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.

> 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.