More adventures in N00bIE administration....

Now... My printers don't print. I have about 20 print queues on my
AIX5.1 machine.

A user can send a print job just fine using: "lp -d printerName
printJobName"

But if they use the command: "qprt -P printerName printJobName" then
the print queue just sits there and says printing, but never actually
prints. It also holds up the next print jobs.

I'm sure you're thinking, "But Dale, why don't you just tell them to
use the lp command instead?" The reason: because most of the users
don't understand what these commands are and they are hard-coded into a
program that makes it easy for the user to print.

Also, because that would not fix the issue as to why the qprt command
is not working.

Anyone have any ideas? I'm willing to try just about anything.

Thanks,
Dale

"Dale" <dalestubblefield@gmail.com> wrote in message
news:1157475123.078583.134820@m79g2000cwm.googlegr oups.com...
> A user can send a print job just fine using: "lp -d printerName
> printJobName"
>
> But if they use the command: "qprt -P printerName printJobName" then
> the print queue just sits there and says printing, but never actually
> prints. It also holds up the next print jobs.

Both lp and qprt both are there just for compatability and don't do much
other than translate the flags and invoke enq. Once the job gets into the
queue (shows up doing an lpstat) processing should be the same.

Try "enq -PprinterName printJobName"

Which you do "qprt" is it "the" qprt or some other script or wrapper or
something around "the" qprt? Or is there some other qprt in the path before
"the" qprt?
which qprt
file qprt

Again, both lp and qprt don't do much other than turn around and call enq so
whatever the difference, it has to be pretty early-on in the process of
getting the job on to the queue.

> Try "enq -PprinterName printJobName"
>
> Which you do "qprt" is it "the" qprt or some other script or wrapper or
> something around "the" qprt? Or is there some other qprt in the path before
> "the" qprt?
> which qprt
> file qprt

I tried "enq -PprinterName printJobName" and the job got hung up just
as if I entered: "qprt -PprinterName printJobName".

However, I entered "lp -dprinterName printJobName" and the job printed
just fine.

I'm not sure I understand your question here:

> Which you do "qprt" is it "the" qprt or some other script or wrapper or
> something around "the" qprt? Or is there some other qprt in the path before
> "the" qprt?

I am just typing these commands from the command line for now.

Dale wrote:
> I'm not sure I understand your question here:
>
> > Which you do "qprt" is it "the" qprt or some other script or wrapper or
> > something around "the" qprt? Or is there some other qprt in the path before
> > "the" qprt?
>
> I am just typing these commands from the command line for now.

I think laixsoft was trying to ask you to verify that when you select
the qprt command, you are actually grabbing the version that comes with
AIX, and not someone's script that they decided to put out there which
was jamming things up.

In other words, when you do the whence, file or which commands, what do
you see?

# whence qprt lp
/usr/bin/qprt
/usr/bin/lp

# which qprt lp
/usr/bin/qprt
/usr/bin/lp

# file /usr/bin/qprt /usr/bin/lp
/usr/bin/qprt: executable (RISC System/6000) or object module
/usr/bin/lp: executable (RISC System/6000) or object module

Steve

Dale wrote:
> I tried "enq -PprinterName printJobName" and the job got hung up just
> as if I entered: "qprt -PprinterName printJobName".
>
> However, I entered "lp -dprinterName printJobName" and the job printed
> just fine.

> I am just typing these commands from the command line for now.

Do you have a background on this issue? For example, were these queues
ever working on this RS/6000 or did this suddenly stop working after an
upgrade or some other change?

Are these printers local to the RS/6000 (using a /dev/lp device) or are
they network printer on HP Jetdirect or other print servers?

The printer queues are generally controlled by three spooler processes.
You can try stopping and restarting them (as root) to see if that makes
a difference, although if lp is working, it probably is not the issue:

# stopsrc -cg spooler
# startsrc -g spooler

>From the sound of things, you may have some sort of corruption in the
software. No one tried to delete root user, got rid of the printq
group, or made global permission or ownership changes in the O/S areas
as far as you are aware? You can compare another system if you have one
to see in /var/lpd or in /usr/bin or /usr/sbin.

Just a thought...

Steve

steven_nospam at Yahoo! Canada wrote:
> Dale wrote:
> > I tried "enq -PprinterName printJobName" and the job got hung up just
> > as if I entered: "qprt -PprinterName printJobName".
> >
> > However, I entered "lp -dprinterName printJobName" and the job printed
> > just fine.
>
> > I am just typing these commands from the command line for now.
>
> Do you have a background on this issue? For example, were these queues
> ever working on this RS/6000 or did this suddenly stop working after an
> upgrade or some other change?
>
> Are these printers local to the RS/6000 (using a /dev/lp device) or are
> they network printer on HP Jetdirect or other print servers?
>
> The printer queues are generally controlled by three spooler processes.
> You can try stopping and restarting them (as root) to see if that makes
> a difference, although if lp is working, it probably is not the issue:
>
> # stopsrc -cg spooler
> # startsrc -g spooler
>
> >From the sound of things, you may have some sort of corruption in the
> software. No one tried to delete root user, got rid of the printq
> group, or made global permission or ownership changes in the O/S areas
> as far as you are aware? You can compare another system if you have one
> to see in /var/lpd or in /usr/bin or /usr/sbin.
>
> Just a thought...
>
> Steve

----------------------------------------------------------------------------------
RESULTS:
[ ----- root ] whence qprt lp
/bin/qprt
/bin/lp

[ ----- root ] which qprt lp
/bin/qprt
/bin/lp

[ ----- root ] file /bin/qprt /bin/lp
/bin/qprt: executable (RISC System/6000) or object module
/bin/lp: symbolic link to /usr/aix/bin/lp.

[ ----- root ] file /usr/aix/bin/lp
/usr/aix/bin/lp: empty
----------------------------------------------------------------------------------

I got my commands mixed up earlier, it's the lp command that is not
working, BUT I asked around the office and the programmers were telling
me that that command has not worked for quite sometime. However, there
is still an issue. I can issue print commands "enq" and "qprt" just
fine as root, but if another user attempts to use them, then the print
job just sits in the queue (lpstat) and never prints.

Nothing has changed that I am aware of and nothing has been installed
lately, except for Webmin. But I do not see how that could affect
this. I installed Webmin the weekend before this past weekend and
everything was fine for two days before we had these issues. The
printers are almost all HP JetDirect printers or they have built-in
network cards. My terminology may be slightly incorrect, but they are
all network printers.

This feels like some sort of permissions issue, but I have checked the
permissions on the /var and /tmp directories along with the permissions
for the "enq" and "qprt" commands. They are set so that everyone has
access, but still only root can use them.

I am printing up a creek without a paddle....

I did try:
> # stopsrc -cg spooler
> # startsrc -g spooler

But I am still getting the same results....

"Dale" <dalestubblefield@gmail.com> wrote in message
news:1157490213.109754.289230@b28g2000cwb.googlegr oups.com...
> RESULTS:
> [ ----- root ] whence qprt lp
> /bin/qprt
> /bin/lp
>
> [ ----- root ] which qprt lp
> /bin/qprt
> /bin/lp
>
> [ ----- root ] file /bin/qprt /bin/lp
> /bin/qprt: executable (RISC System/6000) or object module
> /bin/lp: symbolic link to /usr/aix/bin/lp.

Sounds like the "lp" command on this particular machine isn't the standard
AIX "lp" command. Your "lp" has been replaced with some localized version
/usr/aix/bin/lp

What if you use the full path "/usr/bin/lp -d printerName fileToPrint"

It sounds to me like you just have your own "lp" command which precedes the
regular "lp" executable in your path and that is what isn't working.

Best regards,
Paul

laixsoft@laixsoft.com wrote:
> > [ ----- root ] file /bin/qprt /bin/lp
> > /bin/qprt: executable (RISC System/6000) or object module
> > /bin/lp: symbolic link to /usr/aix/bin/lp.
>
> Sounds like the "lp" command on this particular machine isn't the standard
> AIX "lp" command. Your "lp" has been replaced with some localized version
> /usr/aix/bin/lp
>
> What if you use the full path "/usr/bin/lp -d printerName fileToPrint"
>
> It sounds to me like you just have your own "lp" command which precedes the
> regular "lp" executable in your path and that is what isn't working.
>
> Best regards,
> Paul

I agree with Paul. Try to see if you have a copy of lp in the /usr/bin
directory and see what happens when you run it instead. I would also
check if the directory path /usr/aix contains any readme files or
something that identifies that software.

We had a customer who was using TCPrint and its backend had an issue on
one site. My guess is that you probably have some third-party software
installed that manages the queues or does something special. Example -
converts it to PDF or overlays a form image on blank paper when you
print certain data.

Steve

steven_nospam at Yahoo! Canada wrote:
> laixsoft@laixsoft.com wrote:
> > > [ ----- root ] file /bin/qprt /bin/lp
> > > /bin/qprt: executable (RISC System/6000) or object module
> > > /bin/lp: symbolic link to /usr/aix/bin/lp.
> >
> > Sounds like the "lp" command on this particular machine isn't the standard
> > AIX "lp" command. Your "lp" has been replaced with some localized version
> > /usr/aix/bin/lp
> >
> > What if you use the full path "/usr/bin/lp -d printerName fileToPrint"
> >
> > It sounds to me like you just have your own "lp" command which precedes the
> > regular "lp" executable in your path and that is what isn't working.
> >
> > Best regards,
> > Paul
>
> I agree with Paul. Try to see if you have a copy of lp in the /usr/bin
> directory and see what happens when you run it instead. I would also
> check if the directory path /usr/aix contains any readme files or
> something that identifies that software.
>
> We had a customer who was using TCPrint and its backend had an issue on
> one site. My guess is that you probably have some third-party software
> installed that manages the queues or does something special. Example -
> converts it to PDF or overlays a form image on blank paper when you
> print certain data.
>
> Steve

----------------------------------------------------------------------------------
RESULTS:

[ ----- root ] pwd
/usr/bin
[ ----- root ] ls -la lp
lrwxrwxrwx 1 root system 15 Jun 04 2003 lp ->
/usr/aix/bin/lp
----------------------------------------------------------------------------------

The copy of lp in the /usr/bin is also just a link.

Hmm.... I uninstalled Webmin and now I can print jobs just fine as a
normal user... either it's because I uninstalled Webmin or it's because
there isn't anyone logged onto the server right now... perhaps, it's
not that the jobs were getting hung up, but that the system never could
process them because so many people are logged on during the day that
it slows it down...?

This is why I call it N00bie administration. ;-D

Thanks,
Dale

Dale wrote:
> steven_nospam at Yahoo! Canada wrote:
> > laixsoft@laixsoft.com wrote:
> > > > [ ----- root ] file /bin/qprt /bin/lp
> > > > /bin/qprt: executable (RISC System/6000) or object module
> > > > /bin/lp: symbolic link to /usr/aix/bin/lp.
> > >
> > > Sounds like the "lp" command on this particular machine isn't the standard
> > > AIX "lp" command. Your "lp" has been replaced with some localized version
> > > /usr/aix/bin/lp

On aix 5.1 /usr/aix/bin/lp is in fileset bos.rte.printers 5.1.0.0.
$ which_fileset /usr/aix/bin/lp
$ lslpp -w /usr/aix/bin/lp

Please keep in mind that AIX supports its own print subsystem and the
bsd print subsystem. AFAIK if you change from one to the other AIX just
changes the links for the backend program.

To your problem:
Third party software often installs into /usr/local/bin . If this path
is in front of the user path then any command found there will be used.
- BTW Never ever change the root path to include /usr/local/bin in
front of the path.
Meaning if your webadmin software installs a lp command you - as root -
have no problem but your users might have.
So check what the webadmin software has installed or would install.
BTW: If your using only AIX you and like a GUI then start using the
websm.

BTW2: To trouble-shoot user problems it is pretty handy to have a user
test account with the default setting. So in case a user complains that
something is not working i am using this test account to verify that
problem.

hth
Hajo