v.wales@Ucla-Security@sri-unix (09/02/82)
From: v.wales at Ucla-Security (Rich Wales) Date: 27 August 1982 2208-PDT (Friday) We run 4.1BSD. A few people have suggested the idea of having a print spooler write its process ID in a file, so that queue-managing programs can signal it. My experience is that this can be a disaster in a busy environment unless you are running Berkeley's improved signal-handling stuff. We use home-grown printer software. Our printer daemon normally sleeps until something shows up in its queue; it wakes up every minute or so to see whether anything has arrived. Our "print" and "cancel" programs (like "lpr" and "lprm") send SIGALRM signals to the daemon to wake it up, so that people don't have to wait a whole minute for their request to be acted upon by the daemon. Some time ago, we started having a horrible problem -- every day or so, the printer daemon would unexpectedly DIE. No log-file entry, no core dump -- it would just vanish. Naturally, this was very disconcerting both to our users and to the author of the program (me)! After several weeks, I finally traced the problem down to the fact that the daemon was using "signal" instead of "sigset" to handle SIGALRMs. When things got really busy, the daemon apparently sometimes got two SIGALRMs in rapid succession -- the second one being fatal. Fixing this problem was tricky, by the way, because the "sleep" routine in the standard C library uses "signal". I fixed this by adding to the "jobs" library a "sleep" that calls "sigset" instead of "signal". This way, if you use the "jobs" library, you automatically get a watertight "sleep" routine. The dying-daemon problem has never recurred, needless to say. -- Rich
jim (09/02/82)
I thought everyone (except perhaps the designers of UNIX) was aware of the fact that you can't use normal UNIX signals for IPC because, upon receipt, they revert to the default action, viz., *kill this process*. In our printer spooler (running on PWB, V7, and System III) we used SIGTRAP (not reset when caught); since this was designed in, we never encountered any "horrible problem". The other problem with UNIX signals for IPC is that there is no way to avoid race conditions, thereby missing a signal. We don't use sleep, which works poorly in conjunction with alarm in V7, perhaps less so in System III. We set an alarm for a minute or so and then do a wait (if we have subprocesses running) or a pause, with a check at the last possible moment for the flag which is set by the signal-catch routine. I suppose sigset is fine if you have it, but it ain't UNIX! -- Jim Balter INTERactive Systems --------
derek (09/09/82)
We had a small problem with our print spoolers dying too! Another problem we had is that we could not detect a power off on the printers. Our printers are not on the unibus but have rs232 interfaces and plug into terminal ports. We got around both the problems by adding a terminal type 'p' to getty. If the terminal type is a 'p', our getty does not exec login but rather starts the printer spooler. Because the first terminal opened by the spooler is the printer, the print spooler was part of that terminal's process group and could then see the HUP signal when the printer's power was shut off. Also, if the daemon dies, init will spawn another getty to start it right away. To stop a prin- ter, one merely needs to edit the /etc/ttys file and send a sig- nal to init. Has anybody got a copy of enable/disable that they could send me? Derek Andrew U of Saskatchewan