hdtodd@eagle.wesleyan.edu (03/04/91)
I am running SR10.2 on 2500/3500's with BSD 4.3 as the primary working environment. I have followed the discussion of lpr problems with interest, since I have the infamous "cannot start daemon" problem. I followed the very helpful suggestions of Kniveton about lp? protections and ownership, Peterson about /usr/spool/lpd protections and ownership, Peyerl about /usr/spool/lpd/servername and about /dev/printer, O'Brennan and others about having llbd running. Despite all the helpful advice I still have a very curious problem. If I queue something, lpr/lpd reports that it cannot start the daemon (yes, the master lpd is running). An "lpc restart all" does nothing but report that it can't start the daemon, either. HOWEVER ... if I kill the /usr/lib/lpd master process and restart with /usr/lib/lpd &, the job gets printed (!). The lpd process stays alive, but it can't seem to spawn subsequent daemons to handle new requests. Attempts to log errors with syslogd have been unsuccessful: I asked for almost all levels of lpr errors to be logged with no success. I have verified that /usr/spool/lpd/servername matches hostname, I've check the protections of the directories and lp? programs, and I've verified that there is a /dev/printer and a /dev/sio1. Can anyone suggest anything else I can check. Thanks for any advice. David Todd Wesleyan University
hdtodd@eagle.wesleyan.edu (03/07/91)
In article <1991Mar3.135954.39621@eagle.wesleyan.edu>, hdtodd@eagle.wesleyan.edu writes: > I have followed the discussion of lpr problems with interest, > since I have the infamous "cannot start daemon" problem. <stuff deleted> In trying to work through this, I found that the daemon fails to start if I use a fully-articulated Internet address, e.g., mumble.wesleyan.edu, as hostname and either the full or partial (e.g., "mumble") in file servername. If I use the partial name "mumble" as hostname and as servername, printing is successful. Unfortunately I need the fully-articulated name as hostname to support sendmail. I must have done something stupid when I set up the system six months ago and set up some other configuration parameter to expect just "mumble" -- but I can't find it. Can anyone suggest a solution to this? David Todd
hanche@imf.unit.no (Harald Hanche-Olsen) (03/07/91)
In article <1991Mar6.213032.39820@eagle.wesleyan.edu> hdtodd@eagle.wesleyan.edu writes:
Unfortunately I need the fully-articulated name as hostname to
support sendmail.
Not true, at least not if you are willing to put the hostname
explicitly into sendmail.cf (excerpt from ours):
----------------
# top-level domain we are a part of
DTno
# Next level domain
DAunit
# offical next-level-up complete domain name
DJ$A.$T
# official domain name
Dwimf.$J
# official host domain name
Djhufsa.$w
----------------
In an admittedly longwinded way, this ends up defining the two macros
$w and $j as imf.unit.no (our domain name) and hufsa.imf.unit.no (mail
host name) respectively. I believe $j is used internally by sendmail
and is equal to the machine's hostname if you haven't said differently
in the config file. We use just hufsa for the hostname, and sendmail
performs like it ought to anyway given the above definitions.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYlau@desci.wharton.upenn.edu (Yan K. Lau) (03/08/91)
In article <1991Mar6.213032.39820@eagle.wesleyan.edu> hdtodd@eagle.wesleyan.edu writes: >In article <1991Mar3.135954.39621@eagle.wesleyan.edu>, hdtodd@eagle.wesleyan.edu writes: >> I have followed the discussion of lpr problems with interest, >> since I have the infamous "cannot start daemon" problem. > <stuff deleted> > > > In trying to work through this, I found that the daemon fails to start >if I use a fully-articulated Internet address, e.g., mumble.wesleyan.edu, as > > I must have done something stupid when I set up the system six months >ago and set up some other configuration parameter to expect just "mumble" -- >but I can't find it. > > Can anyone suggest a solution to this? > My experience with lpr no daemon present is as follows. I don't know if this situation applies to you or whether to solution will work in your case. But, you certainly did not do something stupid. I had the same problem. I called Apollo about it. The lpr group stays that the "solution" was to name my machine "mumble". I said that I couldn't do that because we're on a network. He then said he'll forward my problem to the networks group since he doesn't deal with that. The network person calls me, her suggestion was to name my hard disk volume "mumble.wesleyan.edu" to match my network name. Now that is really wierd! I couldn't see our users getting used to that. But I tried it anyway. Turns out both "solutions" work but I couldn't see doing either. Now for my solution: We were running ns_helper. Turns out that when I added fullnames through edns, everyone was happy. My machine are still known by their fullnames to the world. My volume is still the short name. (Side note: totally unrelated, the only wierd effect is the Originator: line above, where is that name coming from? Our rn must be set up wrong.) I hope my experience helps someone else. Tidbits: We are running lpd on all our disked machines. I haven't used the servername so I don't know how that works. Our diskless machines aren't running lpd, lpr doesn't work on them. Our /etc/printcap is set up with the pc= to pass the print request on to prf. We used the lpr command mostly to receive remote printing requests. I'm still looking for some way to stop lpr/lpd from chopping lines at 132 col when sending to prf. Does anyone have a filter for this? Our kludge solution now is to run the file through a wrap program before sending it to the lpr command. We mostly send PostScript files through so 132 col limit messes up printouts. Yan. -- )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ Sheenaphile 128.91.11.233 University of Pennsylvania /\ God/Goddess/All that is -- the source of love, light and inspiration!
hdtodd@eagle.wesleyan.edu (03/08/91)
This is a note on the solution of one possible cause of the "cannot start daemon" problem of lpr/lpd -- thought it should go in the archives in case someone else runs into the same problem. I encountered this problem on DN2500 & DN3500 running SR10.2 with BSD as the nearly-exclusive environment (not using Aegis printing). The Apollo lpr/lpd seems to differ from other BSDs in that it apparently references the Domain name (set by ctnode) as well as servername (created in /usr/spool/lpd by the system administrator). Those names should agree with the Internet hostname. The hostname is set by default to the Domain name (which by default is set to the hard disk name, I think, as Yan Lau suggested in his note on how they resolved this problem). IF YOU MODIFY rc.local TO EXPLICITLY SET THE HOSTNAME (IGNORING THE SAGE ADVICE IN THE COMMENTS THERE), THEN LPR/LPD WILL NOT SPAWN NEW DAEMONS. The best solution might be to get the lpr/lpd sources and recompile, but the easiest solution seems to be: uctnode <your old node name> lcnode -me (get your node number) ctnode <internet hostname you want to be> <your node #> then be sure the lines in rc.local that set hostname are commented out so the hostname will be the Domain node name then be sure that /usr/spool/lpd/servername contains the same name as the Domain name (hostname > /usr/spool/lpd/servername) then carefully check the protections on lpr, lpd, and the various spool directories as suggested in earlier notes on this problem of course, look in the BSD Systems Admin guide for other aspects of the setup such as printcap entries, etc. This approach has the advantage that it doesn't require modifying sendmail.cf to handle Internet mail, etc. (the "I refuse to talk to myself" problem that started all of this!). Many thanks to the wonderful people who thought about this problem and suggested things to look at. I hope I've contributed back a little by making it a little easier if someone else has this problem. David Todd
jf@ap.co.umist.ac.uk (John Forrest) (03/08/91)
In article <HANCHE.91Mar7135242@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: >In article <1991Mar6.213032.39820@eagle.wesleyan.edu> hdtodd@eagle.wesleyan.edu writes: > > Unfortunately I need the fully-articulated name as hostname to > support sendmail. > >Not true, at least not if you are willing to put the hostname >explicitly into sendmail.cf (excerpt from ours): > If you are running BIND, you routinely need to use the full hostname (domain and all). If not, you can do what you like - it all depends on what you make the "official name" in the /etc/host file. Surely? We use BIND, and have lpr/lpd working fine - although we do use prf to do the final printing (I'm not going to get into the other discussion here). What we might do differently is that we gave up trying to have a single lpd server on the network - that is relying on Apollo extensions - and fell back on the basic Unix mechanisms. That is, each host on our network runs an lpd and each has a set of /usr/spool/lpd directories. We basically have two different printcap entries - one machine is nominated as the "print site", and the other machines are set up so that they transfer files to that host (by specifying remote printer and host). That way, if we change the prf entry, there is less to change. There was a bit of problem setting this up, but nothing a shell script could not do - you have to remember to create all the spool directories on each node and especially to set the access rights correctly. The system works fine, and is equally usable using remote printers on other Unix machines. A further point, the /etc/hosts.equiv or /etc/hosts.lpd also have to have full names to work satisfactorily. John Forrest Dept of Computation UMIST