bugzilla-daemon at mindrot.org
2002-May-20 19:01 UTC
[Bug 253] New: Patch to write process ID to a file when ssh sets itself into daemon mode
http://bugzilla.mindrot.org/show_bug.cgi?id=253 Summary: Patch to write process ID to a file when ssh sets itself into daemon mode Product: Portable OpenSSH Version: -current Platform: ix86 URL: http://evan.prodromou.san-francisco.ca.us/openssh- 3.2.2p1.withpid.diff OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: evan at prodromou.san-francisco.ca.us I find it necessary on occasion to write scripts that set up an ssh tunnel, do some commands using that tunnel, and then tear down the tunnel. Tunnelling POP3 connections with fetchmail is a good example: ssh -f -N -L 10110:mailhost:110 mailhost fetchmail localhost [tear down tunnel] The -f option here is key, because you want to be sure that the tunnel is set up before running fetchmail. However, it's difficult to tear down the tunnel, since it's hard to find out what the backgrounded ssh process's PID is. I've written a patch to allow a command-line option, "-d pidfile", which writes the process ID of the fork()'d child to a file, so the script can then just kill `cat pidfile`. In order to do this, I had to unfold the calls to daemon() in ssh.c to actually do the fork(), exit() and setsid() manually, since we want to be sure that the pidfile exists before the parent exits, to avoid races. This works fine on Linux, but I'm unsure if daemon() does any other fancy things on other operating systems. I'm also not sure what the proper behavior of the parent should be if it can't write the pidfile. Currently, it does _not_ kill the child, although this might be the Right Thing. I also changed the manual page to include mention of the -d option. The patch should apply cleanly by changing to the source directory and running: patch -Np1 < /path/to/openssh-3.2.2p1.withpid.diff I hope this is useful to someone else besides me. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.