Undocumented LAT printer "feature" -- save for your records!!
Dietmar Weis
weis at netmbx.UUCP
Thu Mar 28 01:15:14 AEST 1991
lr at cs.brown.edu (Luigi Rizzo) writes:
>In article <7832 at jhunix.HCF.JHU.EDU> barrett at jhunix.HCF.JHU.EDU
>(Dan Barrett) writes:
>>
>> If you have any printers hooked up via LAT, then there is something
>>you should know. According to Ultrix Software Support, you should NEVER
>>associate your very first LAT tty with a printer: it causes unpredictable
>>glitches.
>> ... details omitted
[...]
>said "sleeping for 60 seconds". Then the printer started again for a
>while, stopped again "sleeping for 120 seconds", and so on, the daemon
>being apparently more and more tired and doubling its sleep time after
>each attempt. After several days of work being unable to solve the
>problem (the Digital support wasn't able to replicate it nor it was a
>known problem) I gave up and went back to Ultrix 2.2.1, which is our
>current release.
> Did someone else experience such a problem ?
> Luigi
>==================================================================
>Luigi Rizzo Brown University & Univ. di Pisa
>e-mail: lr at cs.brown.edu, luigi at iet.unipi.it
>==================================================================
Yes, I did. It occured on a DECsys3100 with 4.0 on a friday.
There wasn't anybody there, who could manage the lpr spool
system (thats another story) BUT:
Further printing on that port was impossible, the weekend came.
Till monday there must have sth accumulated, shortly after the first
logins the system CRASHED ! And became unbootable rsp. could not be
brought back to multi user mode.
The PANIC and other messages pointed out the spool or lat system.
Booting to single user mode, cleaning the lpr system, powering off
the terminal server and starting and stopping lat resolved it.
The lp error log was filled with "sleeping for ... seconds" and
"socket in use", the PANIC messages were sth like "print locks held
by nonexisting process" and other stuff which I can't remember at
the moment.
I can't remember if lat port 1 was involved but I know that there IS
a printer on port 1
I inspected the printcap again, called DEC and then included the
ct and uv keywords and the [io]f=/usr/lib/lpdfilters/xf.
The "sleeping" error has obviously gone, but the "socket in use"
error still appears. It stopps printing as well. It happens when
you power off the printer during printing.
Then you have to log on to the server and logout the port,
clean and restart the spool queues. Very annoying.
Many other mysterious things happen, also with terminals. Some times
they are dead, and again, the ports have to be logged out.
BTW, the server is an emulex p4000 with beta release software
(as mentioned in the release notes). (No problem with this server
and software on a vms system.)
Its very frustrating, because the customer is getting nervous and in
the near future propably angry. I count on the patches I will
receive next week or so.
Dietmar
--
============================================================================
weis at netmbx.UUCP | Dietmar Weis DONOP CONSULT GmbH
Voice: 030/884 28 54-0 | Uhlandstrasse 179/180
Fax: 030/882 55 29 | D - 1000 Berlin 12
============================================================================
--
weis at netmbx.UUCP | Dietmar Weis DONOP CONSULT GmbH
Voice: 030/884 28 54-0 | Uhlandstrasse 179/180
Fax: 030/882 55 29 | D - 1000 Berlin 12
More information about the Comp.unix.ultrix
mailing list