On Sat, 04.12.10 11:41, Andrey Borzenkov (arvidjaar@xxxxxxxxx) 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. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
