Xref: utzoo comp.sys.3b1:159 news.software.b:6853
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!n8emr!uncle!donlash
From: donlash@uncle.uucp (Donald Lashomb)
Newsgroups: comp.sys.3b1,news.software.b
Subject: Re: SMGR/Crontab Problem on 3B1 kills newsrun
Message-ID: <1991Feb8.030832.10976@uncle.uucp>
Date: 8 Feb 91 03:08:32 GMT
References: <1991Feb7.055142.21744@colnet.uucp>
Reply-To: donlash@uncle.UUCP (Donald Lashomb)
Organization: U.N.C.L.E.
Lines: 22

In article <1991Feb7.055142.21744@colnet.uucp> res@colnet.uucp (Rob Stampfli) writes:
=I have just been experimenting with a problem I had with cnews running on
=an AT&T Unix-PC (3B1) (3.51m OS).  Occasionally, newsrun would terminate
=prematurely, leaving partially uncompressed files.  No news was lost -- the
=problem was self correcting on the next invocation of newsrun.  It did leave
=partially uncompressed news files in the incoming news directory, though.
=
=I traced this problem to the use of the <MSG> key on the console -- apparently
=all processes attached to w5 (SMGR) get the SIGINT signal (Signal 2) each time
=the <MSG> key on the console is depressed!  The scenerio goes like this:
[...]
=For us 3B1 owners, I think we need to investigate what the full implications
=of this phenomenon are.  Obviously, the use of the <MSG> key can interfere
=with the execution of crontab processes if they are not explicitly protected.
=Anyone have any ideas?

You might want to try my version of cron (recently posted to alt.sources and
unix-pc.sources).  Crontab jobs in my version run unattached to any tty.
BTW- you also get at(1), batch(1) and user crontab(1) with my cron.

Unabashedly,
Don		donlash@uncle.UUCP