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

Lennart Poettering lennart at poettering.net
Thu Jan 6 16:38:27 PST 2011


On Sat, 04.12.10 11:41, Andrey Borzenkov (arvidjaar at gmail.com) 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:

Are you suggesting that mdadm forks off mdmon from within the user
session? This is horribly ugly and broken and they shouldn't do that.

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

Well, only if you enable that the user session is completely killed on
logout, which we currently don't do by default.

I wonder if it would make sense to add an option which kills user
sessions on log out only for uid != 0. This might help here, but only
half-way, since sudo would still break. But anyway, I'll add this to the
todo list.

> It results in dirty array on next boot.

Hmm, that shouldn't happen.

> Is there any magic that allows daemon to be exempted from killing?

Well, I have been discussing this with Kay and we'll most likely add
something like DontKillOnShutdown=yes or so, which if added to a unit
file will exempt it from killing during the normal service shutdown
phase, and the first killing spree (but not the second, post-umount
killing spree). But that of course would require mdmon to be started
like any other daemon, and not forked off mdadm.

That should mostly fix the problem, but then again I do believe that the
whole idea of mdmon is just borked, since it will necessarily pin page
from the root fs into memory which will create all kinds of problems,
for example after upgrades (i.e. mdmon maps libc into memory, libc gets
updated, the old libc deleted, which cannot be written to disk as long
as mdmon stays running pinning it, which will disallow the ultimate
unmounting/remounting of the fs).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list