rdp@pbseps.UUCP (Richard Perlman) (08/19/88)
We are running AT&T's lp on our Symmetry (DYNIX 3.0.12) and have
been experiencing som "oddities" with the system. (Note: this
is Sequent's release of lp, we have a dual universe system.)
1. Print jobs seem to stop for no obvious reason
before they are realy finished although lp thinks
it is done spooling.
2. Print jobs get messed up/garbaged as though there
was no flow control. In fact, I have tried both
CTS/RTS and XON/XOFF and verified that both are
working (using a breakout box).
3. When using _lpr_, and a job was active, I could NOT
stty (stty </dev/ttyxn) the port. The stty request
was held until the lpr job finished.
With _lp_ I CAN stty the port (stty >/dev/ttyxb)
during a job, and found out that lp is using the
_new_ tty driver, but resets back to the old driver
after the job is done. Other than the driver itself,
nothing seems to be changed.
4. At times (seemingly random) an lp job simply won't
print unless I disable and (re-)enable the printer.
5. Lp seems to use up a lot of inodes (pstat -T) and
may not be closing files after printing them. (This
is suspected, but not yet verified.)
Have you experienced any of these problems, or better yet, do you
have a fix. BTW, we have disabled lpr and are only running lp.
--
Richard Perlman * pbseps!rdp@PacBell.COM || {ames,sun,att}!pacbell!pbseps!rdp
180 New Montgomery St. rm 602, San Francisco, CA 94105 |*| (415) 545-0233ronc@cerebus.UUCP (Ronald O. Christian) (08/23/88)
We have seen all these problems on a Vax running SysV from
AT&T, and have seen them also on the Dynix SysV emulation.
One that I would add that I have also seen on both systems
is that sometimes the lpsched daemon fails to start on boot.
I just assumed that Sequent copied the original buggy AT&T
code verbatum to Dynix.
Currently we have both lp and lpr up, but the interface scripts
for lp are diddled to call "ucb lpr" with the appropriate arguments.
The pluses of this arrangement are that (1) you can use lp to access
printers on Ethernet (like our Imagens) or remote printers that the
AT&T code doesn't support, and (2) it gets rid of some of the bugs
in lp. (The flow control problems, for instance.) The minuses are
that the lpsched daemon still doesn't always start on boot, and the
lp queue still gets jammed occasionally. I have considered putting
something in crontab to periodically look at the lpsched deamon and
restart as necessary, but haven't tried it yet.
Most users here use a shell script that calls "ucb lpr $*" and use
the lpr options when they have to perform work in the att universe.
My experience is that lpr is much more robust than lp. (Dynix 2.1,
Dynix 3.0, and both SysVR2 and 4.3 BSD on a Vax 11/780.)
Ron
--
Ronald O. Christian (Fujitsu America Inc., San Jose, Calif.)
{amdahl, pyramid, sun, unisoft, uunet}!cerebus!ronc
Calling all Fujitsu Usenet sites! Contact cerebus!ronc or
ronc@fai.com to establish uucp connection.papowell@attila.uucp (Patrick Powell) (09/08/88)
In article <929@cerebus.UUCP> ronc@cerebus.UUCP (Ronald O. Christian) writes: > >We have seen all these problems on a Vax running SysV from >AT&T, and have seen them also on the Dynix SysV emulation. Have you tried PLP, my reverse engineered version of the Berkeley LPD, available using anonymous FTP from julius.cs.umn.edu, pub/PLP.tar.Z, and pub/PLP.mods.Z? PLP - The Public Line Printer Spooler A Portable UNIX Line Printer Spooler Release 2.0, 1 June 1988 Prof. Patrick Powell Dept. of Computer Science University of Minnesota, Minneapolis, Minnesota PLP is a reverse engineered version of the Berkeley LPD software. The functional resemblance between PLP and the Berke- ley Line Printer Spooler (LPD) is intentional; the source code was written without reference to the original Berkeley LPD software, except for some very small sections concerned with net- working and the large characters used for banner printing. The PLP software has the following features: 1).The PLP software is intended to be used in a Networked File System (NFS) environment, in which there is a common set of spool queues, as well as in a loosely coupled environment in which each host transfers print jobs to a host which has the printer. 2).Access and permission to use PLP functions is controlled by entries in a printer permissions file (/usr/spool/lpd/printer_perms.<hostname>) which can restrict use by user name, host, spooler, page useage, and a host of other factors. The printcap file (/usr/spool/lpd/printcap.<hostname>) is used to specify the printer queues and their operation. 3).Jobs can now be prioritized. The maximum priority a user can specify is set in the printer permissions file. 4).In addition to the general printer permissions file, each spool queue can have its own addition printer permissions file. 5).Line printer control functions can be exercised from a remote host. Hosts and users with remote control permission are specified by entries in the printer permissions file. 6).Unspooling of jobs can be performed by a printcap specified program, rather than by the PLP unspooler. This allows PLP to be used as a spooler and to have spool queues used for various purposes. 7).Extremely verbose and chatty error messages have been added. These greatly ease debugging and installation. In addition, the checkpc utility can be used to set file permissions and other items for use by the PLP software. 8).The code is quite portable, with as few system dependencies in it as possible. It has run on a VAX 4.2, 4.3, and ULTRIX, SUN 3.0, DG-UX, and DYNIX. September 8, 1988 Prof. Patrick Powell, Dept. Computer Science, 136 Lind Hall, 207 Church St. SE, University of Minnesota, Minneapolis, MN 55455 (612)625-3543/625-4002