Crapintosh

Posts you want to find years later go here.

Crapintosh

Postby Zekmyr » Wed Jan 28, 2004 7:36 pm

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.
Zekmyr
Chump
 
Posts: 51
Joined: Tue Nov 04, 2003 5:08 pm

Re: Crapintosh

Postby VLSmooth » Wed Jan 28, 2004 8:40 pm

Zekmyr wrote:Anyway have any experience running a Crapintosh network have any suggestions beyond throwing the damn thing out the window?

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).

Oh yeah, make sure no one is underneath the target location for liability purposes...
User avatar
VLSmooth
Tenth Dan Procrastinator
 
Posts: 3048
Joined: Fri Jul 18, 2003 2:02 am
Location: Varies

Postby VLSmooth » Wed Jan 28, 2004 8:43 pm

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?)
User avatar
VLSmooth
Tenth Dan Procrastinator
 
Posts: 3048
Joined: Fri Jul 18, 2003 2:02 am
Location: Varies

Postby Zekmyr » Wed Jan 28, 2004 9:08 pm

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
Zekmyr
Chump
 
Posts: 51
Joined: Tue Nov 04, 2003 5:08 pm

Postby Jonathan » Thu Jan 29, 2004 12:46 am

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.
Jonathan
Grand Pooh-Bah
 
Posts: 6181
Joined: Tue Sep 19, 2006 7:45 pm
Location: Portland, OR

Postby Zekmyr » Thu Jan 29, 2004 11:10 pm

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
Zekmyr
Chump
 
Posts: 51
Joined: Tue Nov 04, 2003 5:08 pm

Postby Jonathan » Thu Jan 29, 2004 11:30 pm

Methinks that the clients talk to the daemon lpd on the server. Try looking in the appropriate places for the lpd daemon's logs and configuration.
Jonathan
Grand Pooh-Bah
 
Posts: 6181
Joined: Tue Sep 19, 2006 7:45 pm
Location: Portland, OR

Postby Zekmyr » Fri Jan 30, 2004 6:15 pm

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
Zekmyr
Chump
 
Posts: 51
Joined: Tue Nov 04, 2003 5:08 pm

Postby Jonathan » Fri Jan 30, 2004 9:37 pm

Try to generate a crash by printing to the bad queue. If that happens, then you've isolated the fault at least.

Can you print to the queue from the server, thus taking the network out of the equation?

Perhaps there is an update to lpd/lpr which you can try.
Jonathan
Grand Pooh-Bah
 
Posts: 6181
Joined: Tue Sep 19, 2006 7:45 pm
Location: Portland, OR

Postby quantus » Sat Jan 31, 2004 3:26 pm

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

Heh, definately a risc processor and not x86 with all those registers. Ah, at least Macs did one thing right.
Have you clicked today? Check status, then: People, Jobs or Roads
User avatar
quantus
Tenth Dan Procrastinator
 
Posts: 4704
Joined: Fri Jul 18, 2003 2:09 am
Location: San Jose, CA


Return to The Vault

Who is online

Users browsing this forum: No registered users and 1 guest

cron