This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: systemd and kernel process
- From: Josh Stone <jistone at redhat dot com>
- To: Steve Dickson <SteveD at redhat dot com>, Systemtap List <systemtap at sourceware dot org>
- Date: Wed, 30 Sep 2015 13:25:33 -0700
- Subject: Re: systemd and kernel process
- Authentication-results: sourceware.org; auth=none
- References: <560C2FDB dot 9000709 at RedHat dot com>
On 09/30/2015 11:54 AM, Steve Dickson wrote:
> Hello,
>
> Is there a way for systemd to monitor kernel process?
> By monitor I mean the existence.
>
> Here the story... a systemd service calls a command
> that creates a number kernel process/threads
> then the command exits.
>
> Is there a way for systemd to monitor those kernel process
> even though it was told nothing about them?
I assume you mean that systemd created the kernel threads (indirectly),
and you want *systemtap* to monitor them?
You can use probe kprocess.create, which will hit for all new tasks. It
runs in the context of the parent thread. You can see if "task->mm" is
NULL to tell if it's a kernel thread.
If you need to run without kernel debuginfo, it's about the same thing
at probe kernel.trace("sched_process_fork"), and check "$child->mm".
There's also probe kprocess.start for the first time a new thread is
scheduled onto a cpu. This might be more useful if you want to probe
from the context of that thread itself, rather than the parent. I'm not
aware of an equivalent
Telling whether a new kernel thread came about via systemd is a trickier
question. Probably need to probe something more specific to whatever
you're looking for.