mkhaw@TEKNOWLEDGE-VAXC.ARPA.UUCP (06/06/87)
When I do a "lpc abort ps", the lpd daemon associated with my postscript
printer dies, but the Transcript filters that are the children of the
killed lpd don't die. Is that expected, and if so, why? I expect lpc
abort to get rid of all of them so I don't have to do a "ps" to look for
the filters and kill them myself.
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303denise@cwi.nl (07/15/87)
I responded to this about a month ago, but it never showed up in the newsgroup, so let me try again: In article <13447@teknowledge-vaxc.ARPA> mkhaw@TEKNOWLEDGE-VAXC.ARPA writes: > When I do a "lpc abort ps", the lpd daemon associated with my postscript > printer dies, but the Transcript filters that are the children of the > killed lpd don't die. Is that expected, and if so, why? I expect lpc > abort to get rid of all of them so I don't have to do a "ps" to look for > the filters and kill them myself. > > Mike Khaw Simply put, this is a Transcript bug. The source for lpd clearly states that all filters should be killable, but pscomm creates children that ignore signals. The reason they do this is that pscomm works as two processes which communicate with each other, and if one were to die, the other would wait -- forever. The setup (in pscomm) of having two communicating processes has several problems. After trying for awhile to fix some of them, I simply gave up and wrote a new pscomm. My version uses only one process, and uses the bsd select() call to handle `asynchronous' communication with the laser writer. So far (which is four months of heavy usage), we have had no problems with it. If you are interested, send me some e-mail. (Because I borrowed heavily from the original Adobe source, I can only distribute this to people who already have Adobe source). Denise Draper denise@mcvax.cwi.nld ...!seismo!m<2e by!gON.E