> > Hi,
> > I'm working on a program that involves 3, maybe 4 executables. One
> > starts the others then waits for one to die.
> > Question: is it possible for a process which receives a signal to know
> > the pid of the sender? In my case, the parent gets a signal from one of
> > three children: which one sent the signal.
> In your first paragraph, it sounds as though the parent is doing
> nothing except waiting for SIGCHILD. If this is the case, simply
> call wait(3). It will return the pid of the child which died.
> The task as you describe it can be implemented in various ways using
> IPC mechanisms, but you have described nothing here which justifies
> the additional complexity incurred with their use.
> If after reading wait(3), you believe you still need IPC stuff, then
> please provide the additional information.
Well, I really didn't want to get into this, but yeah, I'm also using
IPC stuff. I have a message queue for managing an error queue, I'm
using a mmap'd file to hold shared setup and readings memory. The
mmap'd file may eventually be turned into a SYSV shared memory segment
(since mmap'ping a file on a RAM disk wastes space, no?)
What I have is an embedded PC104 computer/32MRAM, 12 Meg Flash Disk, and
8 serial ports, and an IEEE-488 port, which will talk to a machine
controller (a 6809 system from the 80's) and 4 HP34970A's. Each has a
scanner with 20 channels, for a total of 80 channels. It also controls
up to two Kepco power supplies, 5 ea. 60 amp mercury relays and a 20KHz,
1V oscillator. The purpose of all this is for taking redundant leakage
current and contact verification measurements on tanatalum capacitors in
production (40 every 7 or 8 seconds, but the measurement has to be less
The program consists of two main programs, a module called rltscan which
handles all sequencing and datacomm to/from the HP meters. Another
module is a IEEE488-2 w/SCPI language interpreter. The SCPI interpreter
handles all communications with the outside world. In fact, more than
one SCPI interpreter may be running simultaneously, allowing maintenance
and QC personnel to watch the data and verify operation (the latter
really a debug function). They are not completely in sync with each
other. Kindof hard to some up in one paragraph.
There is an executive program, rlt (redundant leakage tester), which
starts the interpreter, then the scan, then the stats. For a
functioning instrument, there must be one SCPI and one scan process
running. If one of them dies, it must be restarted. stats is optional.
Now back to my problem, The only reason I want to know which process
sent the signal is for debugging a problem I'm having with the fork/exec
sequence of the optional stats program (one that is going to gather data
and calculate statistics for each of the 80 channels and offload the
processing from the 6809).
I fork, then try an execvp(blah,blah). When the exec'd program
successfully starts, finds everything right, it sends back a SIGUSR1. If
the exec fails, I get a SIGCHLD, but every now and then, something goes
wrong and I get a signal I can't figure out where from. I've got a lot
of debugging information stuff going through syslog, every signal I
send, every signal I receive, etc.
I was just looking for a way to trace that stray signal. So is there a
way to know who sent a signal? (BTW, this particular problem is solved,
but I'd still like to know the answer, it'd make reading the debugging