Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!smoke!clapper@nadc.arpa From: clapper@nadc.arpa Newsgroups: net.unix-wizards Subject: System V and the Hangup Signal Message-ID: <3518@brl-smoke.ARPA> Date: Wed, 3-Sep-86 10:26:07 EDT Article-I.D.: brl-smok.3518 Posted: Wed Sep 3 10:26:07 1986 Date-Received: Wed, 3-Sep-86 21:00:27 EDT Sender: news@brl-smoke.ARPA Lines: 49 We are running System V Release 2.0 on a VAX 11/780, and we've encountered a very strange problem regarding handling of a hangup signal. Our software is comprised of several concurrently-running background processes, which trap the hangup signal. One of these processes is a "master" process of sorts; this process synchronizes clean-up processing after hangup has occurred. It sends a message to the one remaining process, "telling" it to terminate. Further, it removes a number of IPC structures and files. Now we come to the problem: If I send a hangup signal to this master process using a "kill -1 ...", clean-up proceeds without a hitch. If I log off the system by entering a at the shell prompt, clean-up also works perfectly. If, however, I disconnect the line (a hardware hangup, if you will), the master process never finishes its clean-up. Files which should be deleted often aren't. IPC structures which should be removed often remain in the system. It's as though the process was killed before it completed its job. I've encountered this problem in three contexts: 1. On a direct-connect line, where disconnect is achieved by shutting off the power to the terminal. 2. On a dial-up line, where disconnect is achieved by physically unplugging the telephone line. 3. From a local cable network, which allows one to call a port on the machine, and where disconnect is achieved by an "escape" command to the network controller. This problem also occurs with Kermit, which doesn't remove its lock-file if the user logs off the system using a "hardware" hangup. To make matters even more confusing, if I run a small test program which does nothing but trap hangup and write a message to a file when hangup occurs, I cannot replicate the problem. The test program traps the hangup signal no matter how it is generated. We've speculated that both our software and Kermit are using some other feature of the system which somehow inhibits proper hangup processing, but we have been unable to gather additional information. Our S.A. is also stumped. Has anyone else encountered this problem? Or, does anyone have a clue as to its cause? Our application MUST be able to trap all forms of hangup, so this problem kind of puts us in a bind. I intend to call AT&T support, but based on past experience with them, I'm don't expect much relief. Please address any replies directly to the E-Mail address below; I often miss issues of UNIX-WIZARDS. Thanks in advance to anyone who can help. Brian M. Clapper clapper@nadc.ARPA Naval Air Development Center Warminster, PA