lp:unable to print file:server-error-service-unavailable
 

I've seen all kinds of posts on the net describing a similar problem to this - but no real solutions or explanations that make sense to me. Here's what's happening:

I have fedora Core 3_64 running on an Athlon 64 3000+ server with a RAID5 arary, 1GB RAM, couple of other EIDE drives I'm using for backups, and several users on the system. I have developed an intense dislike for CUPS (can't get it to work reliably in my environment..) and have installed LPRng on this system - shut off the cupsd daemon. I seem to be able to print fine to all the printers I have connected in various ways whenever I (or any other user) manually ask the system to print something. The lprngtool seems to be able to handle setting up printers and managing them OK (although, It is a bit slow....).

The problem I'm having is when I run a shell script on a crontab that contains an "lp" command: lp -dsystem /absolute/pathname. Whenever the script executes, I get an error emailed to me that states:

lp: unable to print file: server-error-service-unavailable

If I run the very same script from the command line, it seems to be fine. If I enter that same lp command directly at the command line, it works fine.

I -think- this is a CUPS error, but -- in much the same manner as a Microsoft Blue Screen Of Death - there isn't NEARLY enough useful information in this error message to try to debug anything. All it does is tell me there has been a failure - no good indication as to WHY? It doesn't even state for certain that this is a CUPS error, although I -think- it is. The fine folks working on CUPS (and/or FC3) really need to step back a pace here and think about putting some better error messages in place, and leaving the printer-switcher in place until CUPS actually works right FOR EVERYONE. Oops, I'm editorializing.

I -suspect- that perhaps the FC3 kernel and/or the bourne-again shell or cron daemon might have been boogered up to expect that CUPS, and only CUPS, will be providing print services.

Anyway - if anyone out there can help pinpoint EXACTLY what might be causing this error, I'd appreciate the input. Thanks.

I've had this trouble. In one install (the one I'm on now, actually) I had trouble getting CUPS to run for a bit. AFter it was running I noticed that the group name on my /home/username directory had been changed to lpadmin. It sounds to me like you are hitting a permissions barrier, so thought I'd mention the lpadmin thing. I do not know what caused the change or what changed it.

Yes, seems to me I noticed some goofy stuff like that when I had CUPS running too. Now, however I do NOT have cups running, I'm running LPRng. I'll have a peek at the groups in the /root directory (that's he "user" running the cron scripts I'm having a problem with) and see if I can spot anything amiss. Nooooo, I don't see anything here that looks odd. Everything in /var/spool/lpd is owned by "daemon" and is in the "daemon" group - which I'm thinking is probably right since everything prints OK when it's a "live" request. Guess I'll keep looking.

Thanks...

OK - I -think- I have this particular problem solved. In the shell script I was running, I had a redirected print output from the database manager that was originally set to print to a specific printer - which WAS a proper printer and was correctly set up and working. Somehow, redirecting the print output in the background cron process boogered that up (???? no idea how/why). It -seems- to have been fixed by just going into the original print output definition and removing the specific printer, letting the defined print output go to the system default printer. Now, I don't get the error and the print output is redirected as instructed. I don't know why this should work, but it seems to.