byron@archone.tamu.edu (Byron Rakitzis) (01/24/91)
I'm configuring the BSD printing programs (lpd, lpr, lpq, lprm, and so on) on our sgi's to talk to a sun 4/150 driving a laserwriter. Setting up the /etc/printcap file was without surprises, but when I try to print a job, I get the following: lpr: connect: Connection refused jobs queued, but cannot start daemon. Now, the sgi is in the sun's hosts.equiv, hosts.lpd, and just to be safe (trying everything now) in /.rhosts. I can't get this to go away. Does anyone know what the problem may be? /usr/bsd/lpr is both setuid and setgid, but I don't know how it's trying to talk over the network. Any experience with the matter is greatly appreciated. Byron. -- Byron Rakitzis byron@archone.tamu.edu
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (01/24/91)
We have it working ok here. We have a 4D/210 & 320 VGX's running 3.3.1. I routinely lpr files from the SGI's to our Sun 4/280 running SunOS 4.0.3. Our system administrator isn't around at the moment, but, I think the only thing he did on the Sun was to put entries in the hosts.lpd file. -- Brent L. Bates NASA-Langley Research Center M.S. 361 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero8.larc.nasa.gov
glen@meteor.wisc.edu (Glen Ecklund) (01/30/91)
In article <11466@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: >I'm configuring the BSD printing programs (lpd, lpr, lpq, lprm, and >so on) on our sgi's to talk to a sun 4/150 driving a laserwriter. >Setting up the /etc/printcap file was without surprises, but when >I try to print a job, I get the following: > > lpr: connect: Connection refused > jobs queued, but cannot start daemon. > >Now, the sgi is in the sun's hosts.equiv, hosts.lpd, and just to be >safe (trying everything now) in /.rhosts. I can't get this to go >away. Does anyone know what the problem may be? /usr/bsd/lpr is >both setuid and setgid, but I don't know how it's trying to talk over >the network. > >Any experience with the matter is greatly appreciated. > >Byron. >-- >Byron Rakitzis >byron@archone.tamu.edu We have the same problem. Sometimes the connection is successful, however, and the print jobs go through. Since we have an old version of IRIX (3.2), and no support, I have put the problem on hold until we get support and an update. I'm hoping the new version will fix it. Frankly, I did a little investigation a few months ago, and I thought it looked like an OS or library problem, but I don't remember what I discovered. Glen Ecklund
sysmark@physics.utoronto.ca (Mark Bartelt) (02/12/91)
In article <11466@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes: > I'm configuring the BSD printing programs [ ... ] [W]hen > I try to print a job, I get the following: > lpr: connect: Connection refused > jobs queued, but cannot start daemon. > Does anyone know what the problem may be? Through one of those amazing cosmic coincidences, I stumbled upon the very same problem this morning, shortly before reading the above-quoted article. The fix is trivial, once you've diagnosed the cause. The problem is due to an interaction between two things ... --------------- (1) Unlike every other flavour of UNIX I've encountered, IRIX exhibits the following behaviour: $ cd somewhere $ ls -l abc xyz l--------- 1 zippy sys 5 Feb 11 09:40 abc -> ./xyz -rwxr-xr-x 2 zippy sys 36392 Feb 11 13:07 xyz $ abc & 1234 $ ps 666 ttyq10 0:03 sh 1234 ttyq10 0:00 xyz <<=== Oh, yeah? 1235 ttyq10 0:00 ps In other words, even though argv[0] is "abc", the process's u.u_comm gets "xyz" stuffed into it. All the other UNIXes I have access to (both 4BSD and System V based) report "abc" as the command name if "xyz" is an a.out; if "xyz" is a shell script, some UNIXes report "abc", others report "sh". IRIX is the only one that reports "xyz" when "abc" is run. Whether this is a bug, misfeature, or (justifiable) design decision on SGI's part, I have no idea. --------------- (2) With this in mind, we take a look in /etc/rc2.d, where we find something like the following: $ ls -l /etc/rc2.d/*lpd l--------- 1 root sys 286 Feb 1 09:05 S60lpd -> /etc/init.d/lpd This in itself wouldn't be a problem, were it not for the situation described in (1) above, combined with what /etc/init.d/lpd actually does: $ cat /etc/init.d/lpd [ ... ] case "$1" in 'start') /etc/killall lpd [ ...] So, when /etc/rc2.d/S60lpd gets invoked at the appropriate time, /etc/killall thinks its name is 'lpd' and kills it before the script has a chance to start the printer daemon. --------------- Fix: Just remove the symlink in /etc/rc2.d, and replace it with a hard link. It seems rather surprising that nobody has noted this problem already. Maybe Byron and I haven't been paying close attention to the postings of late? Or perhaps everyone else who's stumbled across the problem has just silently made the obvious fix, without bothering to report it. -- Mark Bartelt 416/978-5619 Canadian Institute for sysmark@cita.toronto.edu Theoretical Astrophysics sysmark@cita.utoronto.ca