Xref: utzoo comp.sys.3b1:151 unix-pc.general:7483 news.software.b:6849 Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!n8emr!colnet!res From: res@colnet.uucp (Rob Stampfli) Newsgroups: comp.sys.3b1,unix-pc.general,news.software.b Subject: SMGR/Crontab Problem on 3B1 kills newsrun Message-ID: <1991Feb7.055142.21744@colnet.uucp> Date: 7 Feb 91 05:51:42 GMT Organization: Little to None Lines: 27 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 key on the console -- apparently all processes attached to w5 (SMGR) get the SIGINT signal (Signal 2) each time the key on the console is depressed! The scenerio goes like this: Newsrun comes across a control message and sends the news administrator (me) mail. I am on the console and press to see what the mail is. Newsrun gets SIGINT, and terminates. I have changed newsrun to ignore signal 2. Since newsrun is a shell script, this was fairly easy to do. Obviously, this is not a cnews problem. Cnews merely makes the SMGR bug more visible due to the long-running nature of its crontab scripts. I post this to the the news.software.b group only to warn 3B1 users of cnews who might not otherwise see this. For us 3B1 owners, I think we need to investigate what the full implications of this phenomenon are. Obviously, the use of the key can interfere with the execution of crontab processes if they are not explicitly protected. Anyone have any ideas? -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh