Signal, from whom?

Signal, from whom?

Post by Robert Wues » Mon, 14 Dec 1998 04:00:00



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?

(I seem to remember this as a weakness of signals).

Thanks,

Robert

 
 
 

Signal, from whom?

Post by Craig P. Ear » Mon, 14 Dec 1998 04:00:00



> 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?

> (I seem to remember this as a weakness of signals).

I dabbled with something like this for an instrumentation control
system that had a high reliability requirement. I ended up sending  the
PID of the sender with the message being sent. Much like an IP packet.
--
-------------------------------------------------------------------------

MIT Course XIII-A  Missile Subspecialty    
-------------------------------------------------------------------------

 
 
 

Signal, from whom?

Post by Scott A. Whitehea » Mon, 14 Dec 1998 04:00:00



> 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?

> (I seem to remember this as a weakness of signals).

> Thanks,

> Robert

 You could try having each process send a different signal.  Then have the
event handler
for the signal assign a number to a variable before calling the funtion to
handle the
general case for the signal regardles of who the sender is using the value
assigned
to your variable as to tell who sent it.

    Alleyne
Life is a tempary situation, don't take it too seriously!

 
 
 

Signal, from whom?

Post by Robert Wues » Mon, 14 Dec 1998 04:00:00




> > 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?

> > (I seem to remember this as a weakness of signals).

> I dabbled with something like this for an instrumentation control
> system that had a high reliability requirement. I ended up sending  the
> PID of the sender with the message being sent. Much like an IP packet.

Believe it or not, this is for an instrument that is in itself an
instrument control system.

I already have pipes setup for this, but the signal approach seemed like
such a good idea at the time (easier? not).

Robert

 
 
 

Signal, from whom?

Post by Craig P. Ear » Mon, 14 Dec 1998 04:00:00




> > I dabbled with something like this for an instrumentation control
> > system that had a high reliability requirement. I ended up sending  the
> > PID of the sender with the message being sent. Much like an IP packet.

> Believe it or not, this is for an instrument that is in itself an
> instrument control system.

> I already have pipes setup for this, but the signal approach seemed like
> such a good idea at the time (easier? not).

I chose signals over pipes to avoid possible zombie problems. if the
controller spawns all the subprocesses through fork() in order to
create the pipes, there could be problems if the controller dies.

I preferred to have everything running completely separate so if the
controller died, a new one could be started without me having to
figure out how to get a hold of all the pipes that were laying around
out there. I can't remeber why I didn;t want to use named pipes, it may
have been that I saw a way to do it with signals, which really wasn't
too difficult.

--
-------------------------------------------------------------------------

MIT Course XIII-A  Missile Subspecialty    
-------------------------------------------------------------------------

 
 
 

Signal, from whom?

Post by Robert Wues » Mon, 14 Dec 1998 04:00:00





> > > I dabbled with something like this for an instrumentation control
> > > system that had a high reliability requirement. I ended up sending  the
> > > PID of the sender with the message being sent. Much like an IP packet.

> > Believe it or not, this is for an instrument that is in itself an
> > instrument control system.

> > I already have pipes setup for this, but the signal approach seemed like
> > such a good idea at the time (easier? not).

> I chose signals over pipes to avoid possible zombie problems. if the
> controller spawns all the subprocesses through fork() in order to
> create the pipes, there could be problems if the controller dies.

> I preferred to have everything running completely separate so if the
> controller died, a new one could be started without me having to
> figure out how to get a hold of all the pipes that were laying around
> out there. I can't remeber why I didn;t want to use named pipes, it may
> have been that I saw a way to do it with signals, which really wasn't
> too difficult.

I'm confused now.  Are you somehow sending a multibyte message with
signals?

Robert

 
 
 

Signal, from whom?

Post by Raymond Lillar » Mon, 14 Dec 1998 04:00:00



> 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.

Best,
Ray

 
 
 

Signal, from whom?

Post by Raymond Lillar » Mon, 14 Dec 1998 04:00:00





> > > 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.
---- snipage ----
> > If after reading wait(3), you believe you still need IPC stuff, then
> > please provide the additional information.

---- major snipage ----

Well I guess I asked for it. ;)

Quote:> 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
> logs easier).

Is the problem solved because you found and corrected a bug? or did
it get solved because you changed the IPC architecture to get the pid.

Was the stray signal SIGUSR1 or some other signal?  

I assume the stray signal was from one of the child processes rather
than from smoother stray process?  If it's coming from somewhere
other than the child processes, creating a new process group with
setpgrp(2) might help track it down.  This would probably be a good
idea anyhow, that is forcing this group of cooperating processes to
into their own signal group.

AFAIK, there is no direct way to know the pid of the signal sender
without some other means of IPC, unless the signal numbers can be
unique to a child process.  You might consider borrowing a signal
number or two which relate to features you are not using if you
only need just a few more.  See signal(7).

I have in the past architected similar systems with message queues
and used select(), (actually we wrote our own select over poll()
because we were on a SysV machine) to figure out which child needed
service.  For this method to work, your parent process must be event
driven.  In our case were were adding events to the X-Window System
event loop in a Tk/Tcl environment.  Once we got it right, it worked
really well.

By the way, using signals to inform the parent that something is
waiting in a message queue is risky business due to the critical section
of code involved between processing the queues and managing the signals.
Ideally catching a signal and processing a message queue would be an
atomic operation.  Sadly, it just doesn't work that way.

Semaphores also can be used.  I agree that pipes (either named or
unnamed) are at best awkward and are to be avoided.

I don't know if any of my ramblings are helpful.  I know I can't give
you the magic bullet you were looking for. I'm glad you have found a
solution to your problem.

Ray

 
 
 

Signal, from whom?

Post by Robert Wues » Tue, 15 Dec 1998 04:00:00




> > 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.

> Best,
> Ray

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
than 2).

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
logs easier).

Robert

 
 
 

Signal, from whom?

Post by Robert Wues » Tue, 15 Dec 1998 04:00:00



> Is the problem solved because you found and corrected a bug? or did
> it get solved because you changed the IPC architecture to get the pid.

> Was the stray signal SIGUSR1 or some other signal?

It was a bug.  I've still got the same signal "handshake" going on.

Kindof embarassing (sp?) but, I'd forgotten to exit() after the exec()
failed. So then I had two rlt's running, the first thinking stats was
running , but not initialized (I do an alarm(3);pause(); to give the
process time to start up, but also to detect a hung condition) and the
second thinking it shouldn't be and something was badly wrong and doing
one of those "I haven't the slightest idea what the problem is so shut
everything down and call the engineer 'cause you can't run this machine"
scenarios. (Maybe I should remove that, but it sure let me know
something was wrong here :-))  Pretty obvious looking back.

Still, you've put down some good things to look at and think about.
Thanks.

Robert

 
 
 

Signal, from whom?

Post by Andi Kle » Tue, 15 Dec 1998 04:00:00



>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?

Except for the special case of SIGCHLD there is no easy way to do that
in 2.0. In 2.1/2.2 you can use the siginfo mechanism for SIGKILL/SIGTERM/
SIGUSR* etc. Simply set the SA_SIGINFO flag in your sigaction structure
when you set up the signal handler and declare the signal handler like
this:

void sighandler(int signum, siginfo_t *info, void *data)
{
        pid_t pid = info->si_uid;
        uid_t uid = info->si_uid;
        ...

Quote:}

-Andi
 
 
 

1. Bug in zcat. Whom do I tell?

Try this with the zcat that comes with SLS:

        $touch nothing
        $zcat nothing

You'll get:

        read error on nothing:  Unknown error.

Here's the output of ident:

/usr/bin/zcat:
     $Id: gzip.c,v 0.7 1993/01/05 13:13:13 jloup Exp $
     $Id: zip.c,v 0.7 1993/01/05 13:13:13 jloup Exp $
     $Id: deflate.c,v 0.6 1993/01/05 13:13:13 jloup Exp $
     $Id: trees.c,v 0.5 1992/12/21 18:56:56 jloup Exp $
     $Id: bits.c,v 0.5 1992/12/21 18:56:56 jloup Exp $
     $Id: unzip.c,v 0.6 1993/01/04 09:03:37 jloup Exp $
     $Id: inflate.c,v 0.6 1993/01/04 09:03:37 jloup Exp $
     $Id: util.c,v 0.5 1992/12/21 18:56:56 jloup Exp $
     $Id: crypt.c,v 0.5 1992/12/21 18:56:56 jloup Exp $
     $Id: lzw.c,v 0.5 1992/12/21 18:56:56 jloup Exp $
     $Id: unlzw.c,v 0.6 1993/01/04 09:03:37 jloup Exp $

-Joel

-----------------------------------------------------------------------------
|_|~~ Germany, Europe. 1943.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded.
 cnc  Bosnia, Europe. 1993.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
-----------------------------------------------------------------------------

2. Since when supports Solaris virtual/sub interface counters?

3. hsfs error (to whom it might concern)

4. : BIND lookup with PPP and LAN

5. Bombarded with packets -- to whom do I complain?

6. Looking for decent quality 3 button mouse

7. pppd-2.4.1 problem - whom to send the bug report?

8. Linux Compression?

9. Back finger to whom finger me

10. BUG in ipfwadm ?!? Tell whom?

11. Foo Bar Whom??? EOF..FOP

12. To whom it may concern

13. Back finger to whom finger me