Xref: utzoo comp.mail.elm:476 comp.unix.xenix:2042
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!bbn!rochester!ritcv!cci632!ccicpg!turnkey!jack
From: jack@turnkey.TCC.COM (Jack F. Vogel)
Newsgroups: comp.mail.elm,comp.unix.xenix
Subject: Re: Elm and XENIX
Message-ID: <182@turnkey.TCC.COM>
Date: 17 Apr 88 22:56:07 GMT
References: <10861@codas.att.com> <150@amcad.UUCP> <13@stanton.TCC.COM> <181@ists> <18@stanton.TCC.COM>
Reply-To: jack@turnkey.TCC.COM (Jack F. Vogel)
Organization: Turnkey Computer Consultants, Costa Mesa, CA
Lines: 32

In article <18@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes:
>In article <181@ists>, mike@ists (Mike Clarkson) writes:
>> In article <13@stanton.TCC.COM>, donegan@stanton.TCC.COM (Steven P. Donegan) writes:
 [deleted text...]
>> > 2) If a user is in elm in some functions and gets disconnected the session
>> >    remains running - SIGHUP appears to have been defused.
>
>In one of it's source modules elm 1.7 traps signal SIGHUP, SCO Professional
>and SCO FOXPLUS also have this 'feature'. I expect it has to do with some
>misguided sense of file integrity. 

For all of those interested the problem here is in the elm 1.7 source file
called syscall.c. It only happens in certain circumstances because the SIGHUP
signal is only ignored while in a function called sys_call(). The comments
in the call indicate that the signal is ignored for sendmail purposes so I
should expect that simply commenting out the line :

			signal(SIGHUP,SIG_IGN);

should take care of the problem. However, I have not had time to look over the
code in any detail, so cannot vouch for all the ramifications of doing this,
nor have I been able to test it yet.

					Good luck all,



-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack@turnkey.TCC.COM