Dear Fellow Managers,
This is a somewhat long message.
My original question:
> I have an AlphaServer 2100 system running Digital UNIX 4.0B and I am having the
> following problems.
>
> When I submit the lpr -P<printer> <filename> command I get the following error
> message.
>
> lpr: connect: No such file or directory. Jobs queued but cannot start daemon.
>
> I checked the locks files, the permissions to /usr/lbin and to /usr/lbin/lpd, I
> checked the permissions of all the lpd*err files. All looks fine, but I still
> get the same problem everytime I try the lpr command.
>
> If I should then enter the /usr/lbin/lpd command by hand, all outstanding print
> jobs will print and then lpd would die.
>
> When I try to start lpd by using the command, /sbin/init.d/lpd start , it does
> not seem like lpd starts at all. The only thing unusual that I have noticed
> (when comparing against another similar system) is that the file /dev/printer is
> missing. Is this normal? If it is not normal, then how do I re-create that
> file?
>
> What else can I check to get this problem fixed?
>
And my last summary:
> It would seem that either my statement of the problem was not clear enough or
> this is not such an easy problem to solve as all that. Nevertheless, I got one
> reply from George Gallen <ggallen_at_slackinc.com> who gave me a command to try
> and observe the result. He said,
>
> "What happens if you do:
>
> cat filename | lp -dPRINTERNAME "
>
> Unfortunately, since the LPD is not running, that command fails. It says no
> daemon active, but the file was queued to print.
>
> Thus far the system cannot print unless an operator or system manager
> periodically enters the command,
> /usr/lbin/lpd
> by hand. When he does this, the system will print all enqueued jobs and then
> cannot print again until someone enters that command again.
The final solution that we had applied was to delete the OSFPRINT410 subset and
re-install it. This subset was not passing the fverify test. Once we did that,
then the printing started working again.
In the meantime, many excellent suggestions came in from several fellow
managers. I shall quote them below and attribute their originators. Again,
thanks very much.
All my comments are in double-star parentheses (** comment **).
>From Rob Hamm <hammr_at_ucfv.bc.ca>
you didn't mention if the printer was local or remote, may make a diff.
also on my 2100 4.0B system
# ls -l /dev/printer
srwxrwxrwx 1 root system 0 Jun 17 13:36 /dev/printer
could be an issue
and something should be written into the logs /var/adm/syslog.dated/<date>/
also look for the error file for that printer in /var/adm
(** In fact, several responses suggested looking in the lpr.log files. I was
unable to find anything suggestive, though. **)
>From adunn_at_nswc.navy.mil
Have you tried:
lpc
down all
up all
restart all
exit
-----
/sbin/init.d/lpd stop
/sbin/init.d/lpd start ?
(** Again, several of the respondents suggested that I try this. I did and it
did not work. **)
>From "Leonard, Roger" <rleonard_at_cvty.com>
get a copy of trace and trace the lpd and see what it says when it dies
(** I am still trying to get a copy of this utility. It sounds like it will
come in handy. **)
>From "Frank Wortner" <frank_at_bondnet.com>
One suggestion would be to edit /etc/syslog.conf and make sure that a line
like this appears:
lpr.debug /var/adm/syslog.dated/lpr.log
Restart syslogd by typing
/sbin/init.d/syslog stop ; /sbin/init.d/syslog start
Now restart lpd.
The next time it crashes, check /var/adm/syslog.dated/*/lpr.log to see if
lpd left any clues.
Hope this helps.
(** Again, Frank suggested the use of the lpr.log file **)
>From Wendy Fong <wfong_at_synacom.com>
Check the /usr/var/adm/syslog.dated/[the latest date - ls -ltr/lpr.log and
daemon.log. See if there are problems with the lpd daemon. That might
give you a clue as to why it's dying.
(** Several others suggested the same thing. I shall list them here. **)
Ken Lawrence, lawrence_at_hl.wes.army.mil
(** **)
Sean O'Connell <sean_at_stat.Duke.EDU>
I have had all sorts of oddities happen...
Is this a local printer (serial or parallel port) or a networked
printer? What does your printcap entry for that printer look like?
What if you kill all running instances of lpd, totally obliterate
the spool directory and recreate it (ower.group = daemon.daemon),
and do an '/sbin/init.d/lpd start' ?
How are you printing: is this printer spooling on another unix
box? are you printing from another unix box to the 2100?
Are you using any funky software (there is some Digital printing
addons) or just the vanilla berkeley printing?
(** This person gave a useful set of questions to ask in pinning down the
problem. **)
>From "Long, Michael" <MLong_at_karmax.com>
Hi,
Have you checked /usr/spool/lpd.lock?
Ensure that there are no lpd daemons running then remove /usr/lpd.lock
Also, when was your printcap last modified? LPD is very fussy about the
contents of printcap. Make a backup copy of printcap then Create a new one
with just one printer entry in it. If lpd then starts you know that the
problem is in the printcap file. You will then have to go through the
printcap line by line or add each printer in one at a time until you find
where the error is.
Hope this helps, let me know how you get on.
(** I had checked the /etc/printcap and it appeared identical to a backup copy
that was on tape **)
>From "SIMEONE, Allan J." <Allan.SIMEONE_at_rp-rorer.com>
Hi,
Just quickly reading your mail, I can only suggest the following, first with
a
question....
Is your system out of resources? If so, from answers past in this list, if
the system is out of resources, the system will start taking resources back.
When it does that, it looks for the processes that are idle for the longest
period
of time, in which case, lpd would be one of them unless printing goes
consistantly
on your system all the time and lpd is always active. That would explain
why you
have to keep restarting lpd.
just my 2 cents.
Allan
(** Lots of swap-space, lots of memory, very few processes active on the system.
Was worth checking, though **)
(**Several also suggested the procedure of killing lpd then following that up by
using /sbin/init.d/lpd stop
followed by /sbin/init.d/lpd start **)
Wayne Sweatt <sweatt_at_dps.state.nm.us>
"Lawson, Gordon" <Gordon.Lawson_at_uk.akzonobel.com>
Brian Desmond <brian_at_chimera.psych.unimelb.edu.au> (** He also suggested a
corrupt /etc/printcap **)
Knut Hellebų <Knut.Hellebo_at_nho.hydro.com>
>From "Schrann, Brian" <schrannb_at_uphs.upenn.edu>
I don't know if I have an answer, but maybe I can help troubleshoot.
1) Is the lpd daemon being started at boot time? Do you have a
/sbin/RC3.d/S65lpd RC script to start the print daemon at boot (S65lpd in
4.0D)???
2) Have you tried using lpc to troubleshoot? It's an interactive lpr
interface that you can check the status of, and manipulate, the print queues
and daemons.
Hope this helps!
(** The system was configured to start lpd at boot time and was attempting to do
so **)
Yours sincerely,
Robert Honore.
Received on Wed Jun 23 1999 - 20:31:04 NZST