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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 2, 2011 at 4:39 PM, Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
> On Wed, 02.11.11 15:18, Williams, Dan J (dan.j.williams@xxxxxxxxx) wrote:
>
>>
>> On Wed, Nov 2, 2011 at 8:29 AM, Lennart Poettering
>> <lennart@xxxxxxxxxxxxxx> wrote:
>> > On Wed, 02.11.11 16:21, Kay Sievers (kay.sievers@xxxxxxxx) wrote:
>> >
>> >>
>> >> On Wed, Nov 2, 2011 at 16:17, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
>> >> > Kernel threads we detect by checking whether /proc/$PID/cmdline is
>> >> > empty, hence I'd suggest we use the first char of argv[0][0] here, to
>> >> > detect whether something is a process to avoid killing. Question is
>> >> > which char to choose for that. I am tempted to use '@'.
>> >>
>> >> Maybe introduce a 'initramfs' cgroup and move the pids there?
>> >
>> > Well, in which hierarchy? I am a bit concerned about having other
>> > subsystems muck with the systemd cgroup hierarchy, before systemd has
>> > set it up.
>> >
>> > I can see some elegance in having all code from the initrd that remains
>> > running during boot in a cgroup of its own, but that's probably
>> > orthogonal to finding a way to recognize processes not to kill at
>> > shutdown. Why? Because there's stuff like Plymouth which also stays
>> > around from the initramfs, but actually is something we *do* want to
>> > kill on shutdown.
>>
>> So how about rather than binaries self modifying themselves as "please
>> don't kill me" with argv[][], shutdown can just avoid process where
>> /proc/$PID/cmdline starts with /run/initramfs?  Then it's up to  where
>> the initramfs runs the binary to determine which instances it wants
>> provenance over versus leaving to the init system.
>
> Nope, whether something should be excluded of killing during shutdown is
> orthogonal to being part of the initramfs. For example, Plymouth
> (i.e. the graphical boot splash thingy) is started form initrd too, but
> we definitely want to kill it on shut down.

In the plymouth case the path would be /bin/plymouth, the initramfs
would need to take special care to run mdmon from /run/initramfs to
identify it as needing the initramfs environment to carry out its
shutdown.

> I am a bit concerned about checks against paths since initrd might play
> some namespacing games and the paths might not appear to the main system
> they way you'd expect.

The initramfs needs to be modified to either tell mdmon it is running
from the initramfs or arrange for /proc/$MDMON_PID/cwd to appear to be
from /run/initramfs.  I only like the latter because it works with
existing mdmon binaries, but we may need shutdown to always leave
mdmon alone...

For user started md arrays the shutdown sequence still goes:

killall --> umount

...and we would need to express::

killall (but mdmon) --> umount --> mdadm -Ss (stops all not in use arrays)

So maybe we do the argv "@" tagging in all cases and systemd never
kills mdmon but arranges for all (stoppable) md devices to be stopped,
then rely on /run/initramfs/shutdown to handle the rootfs blockdev.

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


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux