Original Post:
> I have installed HP JetAdmin software (D.03.15) on a Solaris 2.5.1 Sun
> to print to an HP Laserjet 5si with a JetDirect card.
> I installed the software on one machine which I thought could act as a
> printer server, and then used jetadmin to set up a queue. On lots of other
> Suns, I've set up a remote queue which points to this server
> (lpadmin -p QUEUE -s server ... ).
>
> This works OK, except that the server runs lots of lpNet processes (one for
> every client ?)
> After a few days (when there's lots of lpNets running), the server runs low
> on swap space and printing starts to fail ... sending a simple postscript file
> results in an A4 page with a few lines like this ...
> \004\003%-12345X\c@PJL RESET@PJL EOJ NAME="User ...."
> The only way I've found to fix it is to reboot the server.
> Also, if I reboot the server, the lpsched process on some clients starts using
> 100% CPU, and continues to do that until I manually kill and restart it.
> I've installed lp patch 103959-05 on clients and server.
>
> I can't find anything in the JetAdmin manuals which say what's the best
> way to set up the software. For example, should I install the JetAdmin
> software on every Sun, and have every Sun print directly to the printer,
> rather than via a server ? Or do I just need lots of swap space on the
> server ... anyone know how much ??
Thank you to everyone who replied - I got some useful suggestions from:
Stephen Lee <lee@mailhost.sju.edu>
Cheryl L. Southard <cld@astro.caltech.edu>
D. Ellen March <emarch@pinole1.com>
Kathie Hibbard <hibbard@chaco.Colorado.EDU>
Rick Reineman <reineman1@llnl.gov>
Stephen Tremain <stephent@mailhost.bain.com.au>
Matthew Atkinson <m.atkinson@csl.gov.uk>
Paul Leijen <paul.leijen@tip.nl>
I was interested in whether other people were running the software as a
printserver + clients configuration, or printing directly from all clients.
Only one person said he printed directly from clients - but he said
it worked well and avoided passing requests from machine to machine. Other
people recommended staying with the server/client configuration.
The consensus of opinion was that all the problems I mentioned are to do with
the Solaris printing system. So ...
1) Make sure you have the latest patches installed. The lp patch is 103959-05
Another patch mentioned was tcp (103477-09 or 103582-10 depending on OS).
I already had these patches installed. Also, patch 102964 was mentioned -
I think this is just the 2.5 version of 103959
However, one person said she had no printing problems until after
installing patches ! (I think some of the earlier 103959 patches introduced
new bugs which were then fixed in later 103959 patches - so make sure you
get the latest version).
2) The default action of the lpNet process is to sit around forever. You can
change the default by running "lpsystem -T 0". I tried this and it
definitely got rid of my problem with multiple lpNet processes.
3) Two people said that all the print servers should be set up as bsd - not
s5. (lpsystem -t bsd servername).
One person suggested making sure they weren't set up as bsd !!
I initially had my servers set up as s5. I tried changing to bsd, but some
of the clients stopped printing altogether (with an error message in the
log files that they couldn't connect to lpd on the server). However, other
clients continued to print with the server set to bsd. I'm not really sure
why this should be ... I suspect I have something at different patch levels
on different clients (but not the lp patch which I checked on all clients).
4) One person said if you stop and start the lpsched process, then make sure
/bin/echo is in your path before /usr/ucb/echo. I'm not sure what the
cause and effect of this is.
After trying these things out, I had solved my problem with lpNet (and with
the server running out of swap sapce). But if I reboot the server, I still
get lpsched on some clients using 100% CPU. These seem to be the clients which
won't change from s5 to bsd server configuration.
One person said he was running a new BSD-style printing system which is
standard on 2.6 and is on the optional software CD on 2.5. Apparently this
works well, and works with the Jetadmin software. But I couldn't find
this on my 2.5.1 CDs ... I think I maybe don't have all the optional CDs.
At the end of all this, I was so fed up with 2.5.1 Solaris printing that I
decided to try the LPRng system (public-domain BSD system which comes
with filters for HP Laserjets) ... so far this has looked promising.
Replies ...
--------------------------------------
From: Stephen Lee <lee@mailhost.sju.edu>
I think the JetAdmin software is using your swap space to keep its'
log file. You could create a cron job to move or truncate the log file each day.
It will be named QUEUE.log. You may want to look at it for error messages,
unless you are printing many large files the log doesn't grow very quickly.
--------------------------------------
From: cld@astro.caltech.edu (Cheryl L. Southard)
I've struggled for many years with my hp software on my Solaris computers.
We're running Solaris 2.5 and HPNP D3.15. Here's some of the things I
had to do (and they were ALL useful) to clear up the problem.
1. install the lp patch
2. install the tcp patch (103477-09 or 103582-10 depending on OS)
3. on every client and on every print server, look at the /etc/lp/Systems
file. The 4th column of ever line should be "bsd" and not "svsV".
The sysV transports do NOT work propoerly and everything should
be set to "bsd". I think that the command is
"lpsystem -t bsd <hostname>"
4. tell your users never to type "lpstat" with no parameters. This
contacts every print server and starts up an lpNet process. If
you cannot retrain your users, perhaps you can run the
"lpsystem -T 0 <hostname>" command so that lpNet processes
eventually die, as opposed to sitting around (default value)
forever.
I recall trying about 5 other things, but can't remember them right now
and don't think that they were successful.
--------------------------------------
From: emarch@pinole1.com (D. Ellen March)
This sounds like an LP problem to me. There is a patch
available for 2.5.1 that might put a stop to this.
#103959
You did right to load jetadmin on one server and
have other clients remotely print to it.
--------------------------------------
From: Kathie Hibbard <hibbard@chaco.Colorado.EDU>
hi, I am having the same problems as you are with the
results in an A4 page with a few lines like this ...
> \004\003%-12345X\c@PJL RESET@PJL EOJ NAME="User ...."
for every printout I have too, Except that I only get a few LpNets
started and no problem with the cpu hog ro swap space
although I have a lot configure.. 150Mb. I had this working easily
with the unpatched version of Solaris 2.5.1 but when I moved
to the patched version I had this problem come up to.
I'm wondering if the firmware on the printer needs to be upgraded?
--------------------------------------
From: reineman1@llnl.gov
I'm running an environment just like yours, everything goes to
a server, which runs jetadmin. I've seen an lpNet for each
running job, not each client. The lpNets will die when the
print job is finished also. The only difference is I am running
Suns new&improved BSD style print utility. It looks the same
process wise (lpsched etc...), but these are new programs. Also
uses a printcap style configfile. I think it works back to
Solaris 2.3, it comes on one of the additional CD's with Solaris 2.5,
and is standard on Solaris 2.6. Jetadmin handles the new print stuff OK.
Only other thing that ever gave me a problem is the printers should be
setup as BSD devices not SV. Use lpsystem to view and change these
values, on the server. I'm pretty sure jetadmin installs printers as
BSD devices though.
I've always used admintool to install the client side printer stuff,
been successful so far. Avoid manipulating the jetadmin managed
printers with admintool (or AdminSuite) though, on the server side.
--------------------------------------
From: Stephen Tremain <stephent@mailhost.bain.com.au>
We have been experiencing the same problem here. I can offer a few tips,
but I'm not sure our problems have been permanently resolved.
Do you stop and restart lpsched a lot ? If you are, make sure /bin/echo
is in your PATH before /usr/ucb/echo. Or you can modify the Jetadmin scripts
to include the full path for /bin/echo. Use "/usr/ucb/ps -auxwwwe | grep
lpsched" to check the current environment.
Make sure there are no lp clients that think your server is a BSD server.
Check with "/usr/lib/lpsystem -l". However I don't think you have any
choice with Solaris 2.6 print clients.
We have not been able to identify/fix the problem with the client lpsched
using 100% CPU after a restart on the server. We have to restart lpsched
on all the clients after. We use "/usr/lib/lpshut" and "/usr/lib/lpsched".
I will be very interested to see what other people suggest, as this
problem has been causing us massive headaches. I haven't had a chance to
check it out yet, but I am hoping Solaris 2.6 may have a better system.
--------------------------------------
From: Matthew Atkinson <m.atkinson@csl.gov.uk>
We use jetadmin, with about 65 printers and 23 Sun machines, all of
which run jetadmin (D.03.15), and all of which print directly to the
jetdirect box. One machine runs all the bootp configuration, and the
others then just have a spooler set up for each printer the users might
want to use.
We used to run one machine as the print spooler, but ran into similar
problems as you, and there really is no point in passing the requests
from machine to machine to jetdirect when you can just sen it straight
to the jetdirect box.
In addition to this, we also have a number of Windoze boxes which also
print directly to the jetdirect boxes.
All queues correctly, no machine ever gets overloaded, and the jetdirect
boxes just cope admirably. Much better!
--------------------------------------
From: Paul Leijen <paul.leijen@tip.nl>
Whe use the same jetadmin revision (d.03.15) and it run's on a Solaris 2.5
Sun.
This is the printserver
all the printers who can communicate whit the Jetadmin software are remote
connected to this machine.
That means, only these printers and not older type's.
(see your Jetadmin documentation)
The client's are sun OS 4.1 and Solaris 2.5 also.
Whe did install the folowing patches:
103959 (it's in the suggested patch bundle)
and also the 102964 (disk 2).
And we did not see any of your problems here anymore.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:06 CDT