[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    [osol-code] Signal questions
From:       mws () sun ! com (Michael Shapiro)
Date:       2005-12-27 11:21:56
Message-ID: 200512271914.jBRJEHWG222343 () poptart ! sfbay ! sun ! com
[Download RAW message or body]


> 1. Is there any mechanism to remove a process from the run queue and
> later put it back without notifying the process that this has occurred?
> Sigstop and sigcont don't suffice, because they notify the process.

You can use the /proc PCSTOP and PCRUN directives for this.  man -s4 proc
for more information.  You can also try using our higher-level internal
process control library, libproc, if you like: point the source browser
at usr/src/lib/libproc/.

> And if there is such a mechanism, then is there a way to tell the kernel's
> scheduler to use it instead of sigstop and sigcont for a particular process,
> so that the process thinks that it runs without ever being preempted by the
> scheduler?

Not sure what you're trying to do, but I could imagine some inventive use of
DTrace that would achieve this: DTrace's stop() action is equivalent to a
PCSTOP, so you could write a DTrace script to hit a probe either on
descheduling a process with particular attributes or every so often,
hit it with a stop, and then have another control process later wake it up.

> 2. The man page for kill says that "kill -s sigstop 1000" should send
> sigstop to process 1000, but instead it outputs the error message
> "kill: bad signal". I tried "kill -s stop 1000", "kill -sigstop 1000",
> and "kill -stop 1000" with the same result. Only "kill -23 1000"
> actually works. Is the man page wrong, or is kill broken, or am I
> missing something obvious?

You need -s STOP.  Also you need to make sure you've got a shell which
supports it or use /bin/kill.  Many shells have kill built-ins which
may not support the exact same syntax.

> 3. It appears that sigkill unschedules a process without notification
> and then destroys it, but it appears that there's no signal to
> unschedule a process without notification and then dump its core before
> destroying the process. Is this possible?

This is effectively what gcore() does, which is actually quite a simple
program built on top of a libproc primitive to grab a process and create
a core file from it.  So again you can write a simple variant of gcore
which grabs the process with PCSTOP, dumps the core, adds a PCKILL, SIGKILL
or PR_KLC directive to it, and then sets it running, which will cause it
to die immediately from SIGKILL without ever leaving the kernel.

> 4. Is it possible to dump a process's core (without notifying the process
> when this happens) but not kill the process?

Yes, that's what gcore(1) does.  See usr/src/cmd/gcore for the source code.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

[prev in list] [next in list] [prev in thread] [next in thread]