Jeff, Sorry about any vagueness, our understanding may not have been complete when the documentation was written... If you are in the shell, then the kill man page states: ... -s signal_name sends the signal signal_name to the process instead of the SIGTERM signal. -signal_name is an obsolete equivalent of-s signal_name. -signal_number is an obsolete method of specifying a positive integer which represents the signal to be used (instead of SIGTERM) as the sig argument in the effective call to kill. ... As long as the UID matches, you can send the signal. I've done this many times from my test environment. There is currently _no_ user on the system able to send a signal to a process it doesn't normally have access to. The "privileged user" concept for signals is not implemented. The kill man page lists the available signals, I have frequently used SIGSTOP/ SIGCONT to control processes "in the background" in my test environment. The SIGUSR1 and SIGUSR2 signals are implemented, this should have been clearly documented; the file /usr/include/signals.h shows the names/values of all valid signals. Steve Jeff Kell ([log in to unmask]) wrote: : The documentation about posix signals is rather vague in reference to : what "works as advertised" and what is not yet available. Specifically, : if you are an ordinary user, can you kill -SIGINT a process in another : job/session executing as your own uid? And what specific capability is : required to kill a process under a different uid (SM? PM?). : It would be nice if the operator could send non-fatal signals to a background : process (really great if SIGUSRx signals supported too). : [\] Jeff Kell <[log in to unmask]>