The second fork lets you have two processes: one to run ssh, and the other to catch a HUP signal and do whatever it likes to the ssh server. The problem with your existing code is that when you run exec, the signal handler is cleared; using fork too lets you have one process with a signal handler of your choice, and a second process running ssh.
I'm not sure that this has an advantage over not doing the second fork and just keeping the PID's that ran exec in %PIDPOOL.
| [reply]
[d/l]
[select] |
Well, here's an interesting note. If i fork off only one child, this code works. Doing 2 or more, it won't.
Note: I'm not managing sshd servers. I'm managing the ssh clients. I can prove that my child gets the signal but doesn't propogate outward properly.
All in all, I guess ssh is ignoring me :( I've done it via pipe, open (popen), system, exec.. ssh just doesn't like me :\
----
Play that funky music white boy..
| [reply] |