Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!nsc!tron From: tron@nsc.nsc.com (Ronald S. Karr) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: Modem hangup difficulties under 4.3BSD on a VAX (summary) Message-ID: <4199@nsc.nsc.com> Date: Mon, 13-Apr-87 02:36:50 EST Article-I.D.: nsc.4199 Posted: Mon Apr 13 02:36:50 1987 Date-Received: Sat, 18-Apr-87 17:46:38 EST References: <4183@nsc.nsc.com> Reply-To: tron@nsc.UUCP (Ronald S. Karr) Distribution: world Organization: Rational Swamiconductor, Sanivale Lines: 25 Xref: mnetor comp.unix.wizards:1931 comp.unix.questions:1928 In response to my query about modem hangup difficulties (article <4183@nsc.nsc.com>), I received a number of responses which pretty much verified what I was guessing was the problem, while also verifying that there is no easy answer other than user education. The most succinct response was from Chris Torek: >If you run `make & /dev/null &' and log out, all will be >well. If you rewrite vhangup(), that will fix it too: The problem is >that the virtual hangup vhangup performs is quite weak. Until the >process(es) that were attached to the terminal exit, the driver's >close routine never gets called. All vhangup does is revoke access; >it should sneakily alter file descriptors to point at /dev/null. > >Chris Thanks Chris and thanks also to the several others that responded to my query. The redirection of stdin, stdout and stderr to something other than the terminal solves the problem quite well, as long as users are properly informed that they need to do this, and as long as they remember. -- tron |-<=>-| ARPAnet: nsc!tron@sun.COM tron@sc.nsc.com UUCPnet: {amdahl,decwrl,hplabs,pyramid,sun}!nsc!tron (C)Copyr 1987 Ronald S. Karr; you can redistribute only if your recipients can.