Dunno who else to ask about this, so why not here!
So I kinda run the network for my research group in Grad school, sadly we use Macs, but I don't pay for them, so not much i can do...
Anyway, we have a G4 running Mac OS X server, with 6 E-mac clients scattered throughout the lab. The clients are all setup to print to queues on the server using LPR and then IP printing from the server to the printers.
So, this was working great until suddenly one day recently one of the printers stopped working. Well, kind of. you can print to it directly, but not through the queue on the server. So I'm pretty sure it's a problem with the LPR setup on the server, but I've tried everything from completely deleting it and setting it up again to repairing disk permissions with no luck.
Anyway have any experience running a Crapintosh network have any suggestions beyond throwing the damn thing out the window?
Zekmyr
P.S.- the other print queues setup the same way on the server still work fine. And when i try to print to the malfunctioning queue from my PC I get a printer error/busy message... or sometimes the job submits, and then disappears into the void, never to be seen again.
Crapintosh
-
- Tenth Dan Procrastinator
- Posts: 3055
- Joined: Fri Jul 18, 2003 3:02 am
- Location: Varies
- Contact:
Re: Crapintosh
Make sure the window is pretty high up (at least two stories). We dropped an old broken Apple Laser Printer 6 stories and videotaped it back in the day ^^; (place: "architects leap" in Wean Hall. rectangular spiral starcase from 8th to 3rd floor, with an open air column about the size of a door).Zekmyr wrote:Anyway have any experience running a Crapintosh network have any suggestions beyond throwing the damn thing out the window?
Oh yeah, make sure no one is underneath the target location for liability purposes...
-
- Tenth Dan Procrastinator
- Posts: 3055
- Joined: Fri Jul 18, 2003 3:02 am
- Location: Varies
- Contact:
As for a more (less?) serious response, is the print server configured exactly as it was before?
Having minimal mac-in-trash experience (read as used only when forced due to deadlines), it sounds like the server is using a different address/port and the clients are trying to communicate with the old one.
If this is totally off, I apologize for my lack of mac knowledge... (is that really a bad thing?)
Having minimal mac-in-trash experience (read as used only when forced due to deadlines), it sounds like the server is using a different address/port and the clients are trying to communicate with the old one.
If this is totally off, I apologize for my lack of mac knowledge... (is that really a bad thing?)
Architect's Leap... ahh.. that brings back memories. I think I remember seeing a variety of smashed computer pieces at the bottom actually...
As for your suggestions, it's very possible that could be the problem, but I don't have the first clue how to check it or fix it. The Mac OS X server runs off a Unix backend as you probably know, but my unix isn't very great either. Bleh, our office is on the 5th floor, maybe the window isn't a bad solution after all.
Zekmyr
As for your suggestions, it's very possible that could be the problem, but I don't have the first clue how to check it or fix it. The Mac OS X server runs off a Unix backend as you probably know, but my unix isn't very great either. Bleh, our office is on the 5th floor, maybe the window isn't a bad solution after all.
Zekmyr
-
- Grand Pooh-Bah
- Posts: 6722
- Joined: Tue Sep 19, 2006 8:45 pm
- Location: Portland, OR
- Contact:
Ok, so I have Macintosh printing/networking experience and I have UNIX printing/networking experience, but I haven't used OS X. So I have to interpolate.
Let me repeat the problem statement. You have n printers set up, but only n-1 are currently working. The printer can still print and the other print queues work fine, so it's something wrong with the print queue on your OS X server.
Now, I don't know about OS X, but under Linux you use CUPS to print. If OS X also uses CUPS to print, check /var/log/cups/ for the access and error logs. If it doesn't use CUPS, then find out what the printer spooler is, anyway, and check its error logs.
You can also track down the spool directory for the malfunctioning printer and try dropping shit in it manually. Check /etc/cups or the equivalent configuration file for the spool directory.
Other things to check are the printer description files and the Appletalk connection between the clients and server, but from your problem statement I deem these unlikely to be the issue.
Let me repeat the problem statement. You have n printers set up, but only n-1 are currently working. The printer can still print and the other print queues work fine, so it's something wrong with the print queue on your OS X server.
Now, I don't know about OS X, but under Linux you use CUPS to print. If OS X also uses CUPS to print, check /var/log/cups/ for the access and error logs. If it doesn't use CUPS, then find out what the printer spooler is, anyway, and check its error logs.
You can also track down the spool directory for the malfunctioning printer and try dropping shit in it manually. Check /etc/cups or the equivalent configuration file for the spool directory.
Other things to check are the printer description files and the Appletalk connection between the clients and server, but from your problem statement I deem these unlikely to be the issue.
Hmm... ok, so I checked into some of the things you suggested, but bear with me here because I'm kinda of a n00b when it comes to UNIX stuff.
So it does use CUPS to print and I found the directories and error logs you were referring too. Unfortunately I wasn't really able to get any useful information from them. The one thing I don't quite understand is the way the whole thing is setup. So this CUPS stuff is to print from the server to the printers, but somehow the server acts as an intermediate for the clents (actually the whole lab, PCs and Macs). People print to the server as if it were a printer, using LPR printing and specifying a print queue name. Based on the queue name, the server dumps the job to the appropriate printer.
The problem I'm having must be with the first part of this process, the various clients "printing" to the server, cause you can print from the server to the malfunctioning printer fine, and from the clients directly to the printer fine. Now I have 6 different printers all setup going through the server like this, and the other 5 still work, and this one did until sometime last week.
So would the errors and access attempts for the people printing to the LPR port on the server show up in this CUPS thing, or is this something else?
I hope this makes sense...
Zekmyr
So it does use CUPS to print and I found the directories and error logs you were referring too. Unfortunately I wasn't really able to get any useful information from them. The one thing I don't quite understand is the way the whole thing is setup. So this CUPS stuff is to print from the server to the printers, but somehow the server acts as an intermediate for the clents (actually the whole lab, PCs and Macs). People print to the server as if it were a printer, using LPR printing and specifying a print queue name. Based on the queue name, the server dumps the job to the appropriate printer.
The problem I'm having must be with the first part of this process, the various clients "printing" to the server, cause you can print from the server to the malfunctioning printer fine, and from the clients directly to the printer fine. Now I have 6 different printers all setup going through the server like this, and the other 5 still work, and this one did until sometime last week.
So would the errors and access attempts for the people printing to the LPR port on the server show up in this CUPS thing, or is this something else?
I hope this makes sense...
Zekmyr
Well I haven't found much in the way of useful LPD config files, but I did find a lpd.crash.log file with an large number of crashes reported, especially in the past week. Here is an example:
**********
Date/Time: 2004-01-28 12:41:03 -0800
OS Version: 10.2.8 (Build 6R73)
Host: Diamond
Command: lpd
PID: 5045
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x22006cc0
Thread 0 Crashed:
#0 0x90000e60 in strlen
#1 0x90001c40 in vfprintf
#2 0x90005474 in sprintf
#3 0x0000b828 in 0xb828
#4 0x00004570 in 0x4570
#5 0x00003984 in 0x3984
#6 0x0000aa80 in 0xaa80
#7 0x00006874 in 0x6874
#8 0x00005fac in 0x5fac
#9 0x00003054 in 0x3054
#10 0x00002ed4 in 0x2ed4
PPC Thread State:
srr0: 0x90000e60 srr1: 0x0200f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x90001c40 ctr: 0x90000e40 mq: 0x00000000
r0: 0x90001c40 r1: 0xbffff480 r2: 0x00000000 r3: 0x22006cbc
r4: 0x00000000 r5: 0xfefefeff r6: 0x80808080 r7: 0x000004e8
r8: 0x696e6720 r9: 0x22006cc0 r10: 0xbffff77b r11: 0xa0004318
r12: 0x90000e40 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00010cf4
r20: 0x00000000 r21: 0xffffffff r22: 0xbffff840 r23: 0x00000000
r24: 0x00000000 r25: 0x00000073 r26: 0xbffff8d4 r27: 0x00000002
r28: 0x22006cc0 r29: 0xbffff528 r30: 0x00000006 r31: 0x9000107c
**********
Something tells me this thing shouldn't be crashing so often? Any ideas if this might be the problem and how to go about troubleshooting it?
Zekmyr
**********
Date/Time: 2004-01-28 12:41:03 -0800
OS Version: 10.2.8 (Build 6R73)
Host: Diamond
Command: lpd
PID: 5045
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x22006cc0
Thread 0 Crashed:
#0 0x90000e60 in strlen
#1 0x90001c40 in vfprintf
#2 0x90005474 in sprintf
#3 0x0000b828 in 0xb828
#4 0x00004570 in 0x4570
#5 0x00003984 in 0x3984
#6 0x0000aa80 in 0xaa80
#7 0x00006874 in 0x6874
#8 0x00005fac in 0x5fac
#9 0x00003054 in 0x3054
#10 0x00002ed4 in 0x2ed4
PPC Thread State:
srr0: 0x90000e60 srr1: 0x0200f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x90001c40 ctr: 0x90000e40 mq: 0x00000000
r0: 0x90001c40 r1: 0xbffff480 r2: 0x00000000 r3: 0x22006cbc
r4: 0x00000000 r5: 0xfefefeff r6: 0x80808080 r7: 0x000004e8
r8: 0x696e6720 r9: 0x22006cc0 r10: 0xbffff77b r11: 0xa0004318
r12: 0x90000e40 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00010cf4
r20: 0x00000000 r21: 0xffffffff r22: 0xbffff840 r23: 0x00000000
r24: 0x00000000 r25: 0x00000073 r26: 0xbffff8d4 r27: 0x00000002
r28: 0x22006cc0 r29: 0xbffff528 r30: 0x00000006 r31: 0x9000107c
**********
Something tells me this thing shouldn't be crashing so often? Any ideas if this might be the problem and how to go about troubleshooting it?
Zekmyr
-
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
Heh, definately a risc processor and not x86 with all those registers. Ah, at least Macs did one thing right.Zekmyr wrote:PPC Thread State:
srr0: 0x90000e60 srr1: 0x0200f030 vrsave: 0x00000000
xer: 0x00000000 lr: 0x90001c40 ctr: 0x90000e40 mq: 0x00000000
r0: 0x90001c40 r1: 0xbffff480 r2: 0x00000000 r3: 0x22006cbc
r4: 0x00000000 r5: 0xfefefeff r6: 0x80808080 r7: 0x000004e8
r8: 0x696e6720 r9: 0x22006cc0 r10: 0xbffff77b r11: 0xa0004318
r12: 0x90000e40 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00010cf4
r20: 0x00000000 r21: 0xffffffff r22: 0xbffff840 r23: 0x00000000
r24: 0x00000000 r25: 0x00000073 r26: 0xbffff8d4 r27: 0x00000002
r28: 0x22006cc0 r29: 0xbffff528 r30: 0x00000006 r31: 0x9000107c