Lennart Poettering wrote:
On Tue, 22.01.13 02:33, JB ([email protected]) wrote:
Subsequent starts and stops of the application of course do not
change those process ID and kernel threads because, I can only
assume, they are reused. A kill -9 as root will not even kill them.
The problem I have is that system shutdown times take quite a few
minutes unless systemd has done everything it can to kill these,
correct? This mostly results in a very long delay on a timeout
waiting for dependent processes to die when they never will on
shutdown or restart of the computer or just the webapp service.
So let me get this right: if RTAI is used it will spawn kernel threads
that inherit cgroup membership of the client requesting it?
Yep, I've verified that it is in the same cgroup.
That realls sounds like a kernel issue to me, and should be fixed by
RTAI. I mean, I have no idea what this really is and how it behaves, but
Maybe, maybe not...depends on if that's by design or not. There may be
significant advantages to implementing it this way in the kernel. I
don't know for sure. Maybe the two groups of developers should get
together and start talking.
allowing kernel threads to live in arbitrary user managed cgroups sounds
a bit dangerous to me...
I don't have enough of an understanding of the internal implementation
of cgroups in the kernel to have an opinion or debate on how dangerous
it might be. One of RTAI's selling points is being able to run an
application from user space with about as close as you can get to an
in-kernel hard real time environment on commodity hardware. Dangerous?
Maybe. Useful? Absolutely. Ever written a truly hard real time app?
It's dangerous, quite dangerous in fact. Does that mean it shouldn't be
done? Hell no. It is kind of a downer that the project seems to have
great difficulty keeping up with kernel releases as the most recent
release of RTAI kernel patches is for a 2.6.38.8 kernel. It forces me
back to an FC15 distribution since the newer OS releases will not run
some of those older kernels very well. I'd probably contribute but at
the moment I don't really have the time to do that nor rewrite it for
RTLinux nor any other environment even assuming it would perform as well.
It is frustrating between the two groups (systemd devs and rtai devs).
I posted the same message to the RTAI list to make that group aware of
what I was seeing and how systemd was handling it by default. If you
read the RTAI docs there is an opinionated point of view on RTAI's
design, the design of RT Linux from which it originated many years ago,
and other things like other RTOSes copying RTAI's designs, etc...
Systemd documentation is surprisingly complete and quite good for open
source software. Systemd developers are also clearly opinionated with
it showing more on the list rather than in the reference docs which I
suppose is more appropriate. But again, as I had done once before, I
urge caution in leveraging systemd to enforce or impose upon the
universe of linux/unix software engineers too narrowly the opinions held
by a small group (relatively speaking) about how software should or
shouldn't do what it does.
That all said, you can use KillMode= and related settings to alter what
is killed. See systemd.kill(5) for details.
Thanks!! That is what I was looking for. I'll give it a shot and see
how it does. the "process" value for that param I think is exactly what
I'm looking for. Leave the kernel threads alone, and the RT resources
allocated and just kill the main process.
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
