km@emory.UUCP (01/27/87)
I am running WIN3B the TCP/IP package for the 3B2
on System V Rel 2.0.5 (swapping). I just noticed that
nohup does not prtotect background processes started from an
rlogin or telnet session from termination at hangup.
In fact even when I arrange to have ALL signals ignored by
the process, it still terminates on disconnect.
So far the best I seem to be able to do is use "at" to
schedule the process and inititiate it independently of the
rlogin session.
Can anyone suggest another work around?
If anyone is running the newer unrleased versions of WIN3B
I would be interested in hearing if this is fixed.
--
Ken Mandelberg | {akgua,sb1,gatech}!emory!km USENET
Emory University | km@emory CSNET,BITNET
Dept of Math and CS | km.emory@csnet-relay ARPANET
Atlanta, Ga 30322 | Phone: (404) 727-7963guy@gorodish.UUCP (01/28/87)
>I am running WIN3B the TCP/IP package for the 3B2 >on System V Rel 2.0.5 (swapping). I just noticed that >nohup does not prtotect background processes started from an >rlogin or telnet session from termination at hangup. >In fact even when I arrange to have ALL signals ignored by >the process, it still terminates on disconnect. It's amusing to see evidence that this package is, indeed, probably based on the 4.2BSD code; unfortunately, this confirmation takes the form of the appearance of a really stupid misfeature. The 4.2BSD "telnetd" and "rlogind", for no apparent reason, insist on sending a SIGKILL to the entire session when you log out. You can't arrange to have all signals ignored by the process; the system won't let you ignore SIGKILL. >Can anyone suggest another work around? You might try writing a little wrapper program that does a "setpgrp" and then runs a shell or something, and use this to kick off your background jobs. The SIGKILL is sent to the process group that the session belongs to; the "setpgrp" will detach the process from that process group, and thus keep the SIGKILL from hitting it or its descendants (which will be in the same process group, unless they subsequently change their process group). This particular botch is "fixed in 4.3"; presumably, the Woolongong Group will be picking up the 4.3BSD networking stuff at some point.