How limit print spool file size

[Sebastien Masson]

Hi all,

Someone send a 1.1GB print job on my UNIX box. He fill up my /var then my application crash. I killed the user and now I want to know if something exist in HP-UX to limit the size of a spooled print job.

[A. Clay Stephenson]

There is no such built-in limit. You could script/code a replacement for the lp command which would be found earlier in the PATH than the 'real' lp command. Your code could call the 'real' version after doing some checking. The really difficult part about this project is how to deal with input from pipes. You have no way of knowing how big the input will be in advance. This is a case where user-education is needed.

[Rainer von Bongartz]

I dont't think there is a built in functionality in lp.

I encountered this problem very often and then decided to mount a seperate logical volume into /var/spool/lp/request.

This has the advantage that only this mount point might fill up 100 % but /var will have anough space, so a big print jobs does not blow up your machine by filling /var.


Regards
Rainer

[Rodney Hills]

I turned on disk quotas on /var so that no one user can take all the space (like a run away print job).

It is a bit of a hassle to remember to define the disk quota each time a new user is added, but seemed to be the only way to prevent run away print jobs.

-- Rod Hills

[harry d brown jr]

Wow Sebastien, I think you went a little too far when a good slap would have sufficed: "I killed the user..."


live free or die
harry

[Helen French]

That was funny Harry =))

Sebastien, your thread already got the "rabbit" sign eventhough you didn't assign any points => 8 ! ! !

Something you can report to DAN in the forum issues ..

HTH,
Shiju

[Bill Hassell]

Unfortunately, quotas won't work for lp as all jobs are owned by lp, not the original user. The only way to fix this problem is with the printer script(s). And it is fairly easy since the script is run after the file (including stdin) is copied to the /var/spool/lp/request/ directory. Simply add code to test the size of parameter $6 (and $7, $8 if any) to see if they are too large. If so, you can simply exit (after sending a notice to root) since the file will be immediately purged.

The downside is that the print job must be submitted before it can be checked.

Another technique is to create an lp wrapper (assuming the problem user is using HP-UX and not using a PeeCee to print through HP-UX onto the printer) where the lp wrapper checks the size of the requested files(s).

If the user is indeed using a PeeCee, then turn off spooling for all your PeeCee users...it isn't needed. As you've seen, the /var directory is crucial to operating all of your applications and kernel daemons. Instead, switch all your PeeCee users to network printing (works on Win95 and up through WinXP.

[Rodney Hills]

I forgot about "lp" being the owner. We were having the problem with an application called uniVerse which has its own print spooler.
uniVerse does create the spool file with the owner who submits the print job.

-- Rod Hills