Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (04/01/85)
Unix Technical Digest Mon, 1 Apr 85 Volume 1 : Issue 37 Today's Topics: don't do long jumps in signal handlers I/O redirection to pipes question Passwd on PC/IX Printing in signal handlers vs. setting flags. proper use of su Q: How to preserve process state across logout/login? Rear-end processors for VAX UNIX training, opinions wanted ---------------------------------------------------------------------- Date: 24 Mar 85 12:09:18 GMT From: donn@utah-cs.UUCP (Donn Seeley) Subject: don't do long jumps in signal handlers From: wls@astrovax.UUCP (William L. Sebok) In my opinion, if [Berkeley] didn't want signals to abort terminal reads they should have provided an explicit i/o abort function that could be called from the signal handler. I wrote such a function and posted it to the net some time ago... It was a bit ugly but it worked. I understand that Berkeley may be considering providing a facility for 4.3 BSD that would allow you to specify that a particular signal can interrupt a slow system call. This might be done by changing the on_stack member in the sigvec structure to be a generalized flags variable, and inventing a flag that would tell the system, 'Don't restart system calls when you see this signal.' To quote a recent version of the signal.h file at Berkeley, 'isn't compatibility wonderful!'? -- Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn ------------------------------ Date: 29 Mar 85 20:21:29 GMT From: gsc@druxr.UUCP (CageG) Subject: I/O redirection to pipes question What must be done for a process to exec a child with the childs stdin and stdout redirected to pipes set up by the parent. One of the restraints is that the redirection must be done in the parent process (the child is a tool that I don't want to change the source for). This must be a commonly done thing since it is what the shell does when pipes are used with process's. Send any ideas, information, stuff to druxr!gsc Thanks in advance Gary Cage ------------------------------ Date: 25 Mar 85 19:17:19 GMT From: naftoli@aecom.UUCP Subject: Passwd on PC/IX > I just noticed that the PC/IX login command will accept > the superuser passwd as valid for any user. That is a feature from Interactive and is also available on their IS/3 system for the 750/780. It's *very* useful. -- Robert Berlinger ...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli [Ed note: A bug by any other name would smell as well. :-) RWH.] ------------------------------ Date: 26 Mar 85 19:51:32 GMT From: radford@calgary.UUCP (Radford Neal) Subject: Printing in signal handlers vs. setting flags. If you *must* use signals for something other than fatal error handling, then just setting a flag is usually best. My advice to print an error message and terminate the program was meant for cases where you are just trying to provide a more informative error message than the shell would have given out. By the way, if setting a flag is best, why not add a new option to "signal" that specifies a word in memory to be incremented by the kernel when a signal arrives, as an addition to the current ignore, trap, terminate options. This avoids the problems of restarting system calls when the flag methodology is being used. Radford Neal The University of Calgary ------------------------------ Date: 28 Mar 85 17:31:34 GMT From: phil@amdcad.UUCP (Phil Ngai) Subject: proper use of su On my 780 running 4.2, I sometimes want cron to execute certain shell scripts under user ids other than root, such as uucp and news. Sometimes I can do: /bin/su news < shell.script and sometimes I have to do: echo shell.script | /bin/su news Could someone explain this? thanks -- Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA ------------------------------ Date: 26 Mar 85 15:29:14 GMT From: begeman@mcc-db.UUCP (Michael Begeman) Subject: Q: How to preserve process state across logout/login? I use a network analysis program that takes 1.5 HOURS(!) of cpu time to load and preprocess a very large net. Each of the subsequent analysis queries take only a few minutes. How can I save the state of the process before logout and restore it later? I tried core-dumping it, but couldn't get adb to restart it correctly, and CSH kills any stopped jobs at logout. Restriction: I can't dink with the source...this has to be solved externally. Ideas, wiz? Gracias in advance. -- Michael L. Begeman Microelectronics and Computer Technology Corp Software Technology Program Austin (where the sun always shines) Texas {ihnp4, gatech, seismo, noao, ctvax}!ut-sally!mcc-db!begeman ------------------------------ Date: 28 Mar 85 23:29:03 GMT From: jbn@wdl1.UUCP Subject: Q: How to preserve process state across logout/login? Here's a thought: Write a network daemon. This daemon, when activated, starts up the giant job, which does the precomputation, after which the daemon waits for connection requests. When users connect to it, presumably with TELNET, they can then talk to the giant job via the daemon. The daemon keeps the giant job waiting for input when there is no traffic, until the daemon gets some command via a connection telling it to go away. This is not a trivial job, but shouldn't take more than a few days to get going for someone who knows 4.2BSD reasonably well. John Nagle ------------------------------ Date: 28 Mar 85 00:44:28 GMT From: wcs@ho95b.UUCP (Bill Stewart) Subject: Rear-end processors for VAX > we are looking for micros to hook up to the vax for text > processing type jobs to take some of the loading off of the computers. > ...ihp4!tellab1!tellab2!smith > todd smith We use a Bell-Labs-developed-and-built box called a "PDQ". It's not an externally-sold product, but it's got a commercial 68000 board living on a Multibus with 1/2 Meg of memory, no disk, an RS-232 port, and a small ROM monitor program that lets the host computer download software and data files. It normally has either nroff or troff living in it, plus whatever file it's crunching on at the moment. The host software looks to see if there's a free PDQ, arranges to download n/troff if needed and transmit the file. If there's no free PDQ it uses "real" troff instead. The box costs us about $6K, and a couple of them really improve the performance of our CPUs (we mostly use VAXen and 3B-20s, and do a lot of troff.) The box has about half the horsepower of a VAX 11/780, and minimal operating system software, so you get a lot more CPU/process on the box than on your 1/nth share of the host. The real bottleneck is the RS-232 line (wish we could attach it to Ethernet or a Unibus!), but our printers are attached by RS-232 anyway; you don't lose much for the typical troff-->Imagen jobs. If you don't want to build your own box and ROM monitor, it shouldn't be hard to take a commercial supermicro like the AT&T 3B2 or anybody's 680x0 UNIX box, store a few standard applications on the disk, and use uux or whatever to submit jobs to it. (Anybody ported troff to a Fat Mac?) Bill Stewart, speaking unofficially at AT&T Bell Labs [Ed note: I have heard of people using AT&T 3B2s for this purpose. RWH.] ------------------------------ Date: 27 Mar 85 17:32:59 GMT From: ken@elsie.UUCP (Ken E. Brown) Subject: UNIX training, opinions wanted I received a catalog of UNIX and C training seminars from a group called Computer Technology Group, based in Chicago. If anyone has any experience with their training seminars I would appreciate opinions as to the quality of the seminars, the level of the presentation, etc. Please mail responses to: ...!decvax!allegra!umcp-cs!elsie!ken Thanks in advance, Ken Brown [Ed note: Is this kind of thing appropriate to mod.unix? It is from the net groups, in this case. RWH] ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews} AT&T Information Systems, Inc. Lisle, IL (CU-D21)