If I understand you, you are doing something like this:

if (!fork()) {
  setsid()
  exit if fork();
  ...do child stuff
} else {...do parent stuff}
[download]

According to Stevens (Advanced Programming in the UNIX Environment) that is basically the standard recipe for creating a detached process -- one in it's own session and process group. And since the child's real parent is dead, it was inherited by init (process 1).

So if that is what you are doing, then you are doing exactly the wrong thing to do if you want the child to die when the parent does.

If you want the background process to terminate when the foreground process terminates cleanly (i.e., not from "kill -9"), you could use a flag set by parent when shutting that is shared between processes, or or pass the child's PID to the parent (through shared memory) and send a signal from the exiting parent. If you wanted a SIGINT or SIGKILL to go to both processes, you could use setpgrp() to place the background process in the same process group as the parent (but you can do the same thing by not using setsid).

Why are you using setsid() in the first place?

Where you were not looking was the POSIX module. That is where setsid() is defined.

EDIT
I went and read it closely. Actually it isn't defined there. It just tells you to see your man page.

DESCRIPTION
setsid() creates a new session if the calling process is not a process group leader. The calling process is the leader of the new session, the process group leader of the new process group, and has no controlling tty. The pro­ cess group ID and session ID of the calling process are set to the PID of the calling process. The calling pro­ cess will be the only process in this new process group and in this new session.

The usage in the code is absolutely identical to what my man page (Debian) has to say in its notes about this function.

BTW I have been amazed lately at how good Google is for picking up information on random technical things. For instance here is a search on setsid.

There is no foreground process. It's using setsid() to disassociate the child from the parent, then the parent exits. The remaining process (the child) forks a process it's the parent of and they both do their own thing.

I should have just left out the setsid() because you're apparently confused by what I intended to do with it. I wasn't sure if it was pretinent or not, so I mentioned it.

I'm doing something like this:

use POSIX qw/setsid/;

if ( fork() ) {
    exit;
} else {
    setsid();
}
# now the foreground process is gone and I'm the child
if ( fork() ) {
    &do_something();
} else {
    &do_something_else();
}
[download]

They both stay around in an infinite loop doing whatever they're supposed to do. I have to kill them both or whichever one I don't kill sticks around. Like from ps auxf:

iniquity 26464  0.5 15.9  2976  2348  ?  S   21:41   0:00 perl -w ./si
+ncd.pl 
iniquity 26465  0.0 15.4  2920  2276  ?  S   21:41   0:00  \_ perl -w 
+./sincd.p
[download]

If I kill 26464, 26465 doesn't go away.

local $_ = "0A72656B636148206C72655020726568746F6E41207473754A";
while(s/..$//) { print chr(hex($&)) }
[download]

I vaguely recall in some versions of Unix that process groups and/or sessions implied that signals sent to the process leader got also sent to all members of the process group. However, I also vaguely recall this changing so that this was only true for a "foreground" session when the signals are generated from the controlling tty.

So I don't think you can force this automatic signal propogation in the version of Unix that you are using. I did do some looking in the only Unix man pages I have access to, and got minor confirmation on some of this.

So you might want to read up on setsid(2), setpgrp(2), termio(7), and/or kill(2) for the version of Unix that you are using. In Perl, you can put a minus sign in front of the signal name/number to indicate that you want to kill a process group instead of an individual process.

Well I just want to say thank you all for your help. To summarize, as sr. tye pointed out, signals aren't propegated through process groups, so I have to do that myself. Yuck, but ok. Now I just gotta figure out how to get a SIGINT to break from a blocking IO::Socket::INET::accept (should I use non-blocking? is that possible? I'll figure it out)

So, thank you, especially tye.

local $_ = "0A72656B636148206C72655020726568746F6E41207473754A";
while(s/..$//) { print chr(hex($&)) }
[download]