Hi, I would like to briefly comment on a problem mentioned in the file "TODO" and also in the OpenSSH FAQ (question 3.10), namely the hanging of an ssh connection (on Linux) if there are active processes. It is stated that this has to do with the fact that children of the shell are not killed upon exiting the shell. However, the problem also occurs if a process is started with 'nohup'. This is very annoying, because it is not uncommon to connect to a remote machine, start a lengthy computation with 'nohup' and then exit. My point now is the following: a) the workaround in the FAQ seems useless: after all one doesn't want the new process to be killed. b) the "TODO" file states "All current solutions break scp or leave processes hanging around after the ssh connection has ended." But the latter is exactly what one wants in the case of a nohup process. So wouldn't it be possible to implement one of these "current solutions" for this situation? Many thanks (comments welcome!), Erik Luijten Erik Luijten | Institute for Physical Science & Technology luijten at ipst.umd.edu | University of Maryland Tel: +1-301-405-4821 | College Park, MD 20742-2431, U.S.A. Fax: +1-301-314-9404 | http://pallas.umd.edu/~luijten * After August 17, 2001: MSE/Urbana-Champaign - luijten at uiuc.edu *
On Wed, Jul 11, 2001 at 08:49:23AM -0400, Erik Luijten wrote:> It is stated that this has to do with the fact that children of the shell > are not killed upon exiting the shell. However, the problem also occurs if > a process is started with 'nohup'. This is very annoying, because it is > not uncommon to connect to a remote machine, start a lengthy > computation with 'nohup' and then exit. My point now is the following:Based on someone else's statement and verified by my own observations (HP-UX): the hanging ssh connection is not caused by the child processes, but by the child processes still having file descriptors open. I have since then solved the problem by redirecting the file descriptors command > /dev/null 2>&1 etc etc Of course you may consider something different than /dev/null in order to catch the output... Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
> a) the workaround in the FAQ seems useless: after all one doesn't want > the new process to be killed.Agreed.> b) the "TODO" file states "All current solutions break scp or leave > processes hanging around after the ssh connection has ended." > But the latter is exactly what one wants in the case of a nohup > process. So wouldn't it be possible to implement one of these "current > solutions" for this situation?Yes, such a patch already exists for Linux: http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta