UNIX for Beginners Questions & Answers

Hello Administrators.
I have a bit difficult problem.
I have local virtual printer that has backend defined in /etc/qconf to script which in turns sends the spool to the real device.
whenever I print locally (from sap) the print works as it should. The printer queue after the print is done remains in status ,,ready''.
However i've setup a remote SAP system on SLES12. The SAP can connect to the aix just fine (the lpd daemon is working), but whenever I try to print anything from it the jobs are send to the aix's virtual printer queue and then..the queue gets status down immediately.
Whatever I do I cannot enable the queue when those jobs are in status QUEUED.
To get the queue up, I need to put all jobs on hold with qhold -P command, and only then I can enable the queue.
However enabling any of held jobs , or trying to print anything from remote SAP puts the queue immediately again into DOWN status.

what am I missing ?
the remote SLES system was added to the /etc/hosts and /etc/hosts.lpd file. The AIX clearly accepts job requests since I can see them in the queue.
In my opinion it is not a sap problem but AIXes, which for some reason any remote print requests treats immediately as a reason to put down the whole queue...

thanks in advance for help !
Deneth

Hi,

When you configure the Network Services through YaST can you see the printing services, also you may have to ensure that CUPS is correctly set up.

Regards

Gull04

That could be all sorts of things. Post the stanza from /etc/qconfig from the AIX system. Also look in /var, it could be full, the user missig the necessary privileges, .....

Also, from the AIX system: try a telnet <printers-ip> 515 to see if the lpd daemon there is responding. If the queue is taken down by the OS then there is some reason for it (print jobs arriving are NOT a reason). In any case you can take the queue up again without removing any print job with the command qadm -U <printer> command on AIX.

I hope this helps.

bakunin

Hello,
thank You all for Your replies.
so to answer most clearly :
-telnet on port 515 works fine
-qadm -U printer doesn't bring the queue up. Or maybe it does but then it immediately goes down because of queued remote jobs

-stanza for the virtual printer and printer is as follows from /etc/qconfig : the job goes to virtual printer, which invokes script that adds one line to the job, and then moves the spool to the real printer.
so it goes like this print request -> vBIOM -> script >BIOM

Code:

BIOM:
        device = @printBIOM
        up = TRUE
        host = printBIOM
        s_statfilter = /usr/lib/lpd/aixshort
        l_statfilter = /usr/lib/lpd/aixlong
        rq = BIOM
@printBIOM:
        backend = /usr/lib/lpd/rembak -T60
vBIOM:
        device = vBIOM
        up = TRUE
vBIOM:
        backend = /usr/scripts/backend/BIOM

- /var/ has 500 mb left so I doubt that some spool with 1 page is too much for it.

I 've set the /etc/hosts.lpd and /etc/hosts.equiv as follows :

Code:

/etc/hosts.lpd :
druk

Code:

/etc/hosts.equiv :
druk prdadm
druk root

in my opinion it should work. To which folder do You think I'd need to check privileges?


@Gull04 I don't really think SLES is the issue here. It doesn't do anything except for being a host for sap system (which works as a spool server itself, it doesn't need SLES help in that matter )

Moderator's Comments:

edit by bakunin: Please use CODE-tags for code, terminal output and data. Thank you.

Hi Deneth,

It's been a long time since I've done much serious admin work on AIX, but I have done a fair bit of recent migration work both from and to AIX. From memory and it is a distant one, the LPD setup and the CUPS setup could cause issues as I've not actually got an AIX system to hand that I can test this with I'm going from some notes.

So the smit bit goes like this;

As root;

Check that the LPD daemon is running - must be if the system is printing. But if it's not, start the LPD daemon using SMIT, click Print Spooling → AIX Print Spooling → Manage Print Server → Start the Print Server Subsystem.

Add the host name or IP address of the systems that you want to allow to print to the /etc/hosts.lpd file.

In SMIT, click Print Spooling → AIX Print Spooling → Manage Print Server → Add Print Access for a remote client. Enter the host name or IP address of the system that you want to allow to send jobs to the print queue.

If you run enq -U -P "printerid" does the status change from "connect" to "sending"?

Regards

Gull04

Dear all,
thank you all for Your answers. It stared to work. What did the trick ? The truth is...I don't really know.
It didn't work, but when I restarded spooler and editiet qconfig file (while the queue was ,,ready'') it started to work
so what I did :

1: the queue has staus down
I restared whole spooler with commands :

Code:

stopsrc -g spooler
startsrc -g spooler

2:
I held jobs from the queue

Code:

qhold -PvBIOM

and enabled it again with command

Code:

enable vBIOM

3:
Then I added parameter to the virtual printer definition in qconfig.
it looks like this now (the parameter does not do anything though, when I believed it was supposed to log)

Code:

vBIOM:
        backend = /usr/scripts/backend/BIOM -D /tmp/pst/log

and it worked.

First I released 1 job, then another one , and after that I released all of them and all of them got processed.
The prints are working now.

My guess is that either restarting the spooler did the trick, or editing the qconfig was made at the right time so the qconfig.bin was rebuilt.
I don't really believe that -D parameter helped.

Moderator's Comments:

edit by bakunin: Please use CODE-tags for code, terminal output and data. Thank you.

First off: thank you for describing what led to a solution for you. This way others can build on your thread.

Second: please use CODE-tags for code, data and terminal output like the ones i edited into your posts. This preserves spacing (unlike the HTML your text is transformed into) and lets these parts of your posts stand out. You can also use ICODE-tags for commands like this: use ls to display a directories contents. Thank you for your consideration.

The point is moot now, but the directory i asked you to check the permissions was /var/spool and the hierarchy below it. Since i had no indication of what the problem might be i suggested whatever my mind could come up with as possible reason - privileges was one of them. I actually had this case once when somebody thought to make the systems "more secure" by flagging every directory to 700.We rolled that back (obviously) but somehow /var/spool slipped through and this had similar consequences as the ones you described.

I think your suspicion about rebuilding the /etc/qconfig.bin is right. This most probably was the culprit.

bakunin