/var/spool/*/minfree ignored by lpd

[Joe Ledesma]

Setting up a new application that will use a very large spool file and would like to have a way to prevent the file system from being filled up. lpd(8) says:

DESCRIPTION

The minfree ASCII file in each spool directory contains the number of disk
blocks to leave free so that the line printer queue will not completely
fill the disk.

FILES

/usr/spool/*/minfree
Minimum free disk space to leave.

------------------------

Have tested this with small files on a test system and lpd appears to be ignoring this value.

# cat minfree
518730

Started with more free blocks than this and was able to keep creating spools past this minfree value:

df /var/spool/output
Filesystem 512-blocks Used Available Capacity Mounted on
usr_domain#usr 5505024 4991780 513244 91% /usr

lpd does seem to be reading the file as indicated by the -u flag to ls:

# ls -ltru /var/spool/output
total 2284
-rw-r----- 1 root daemon 19 Aug 12 09:51 lock
-rw-r--r-- 1 root daemon 0 Oct 14 09:43 lp.out
-rw-r--r-- 1 root daemon 2327580 Oct 14 10:06 lp0.out
-rw-r--r-- 1 root daemon 7 Oct 14 10:11 minfree
-rw-r----- 1 root daemon 4 Oct 14 10:12 .seq
-rw-rw-r-- 1 root daemon 27 Oct 14 10:12 status

Have tried minfree both ending with a line feed and without.

Supporting an application that can convert a document to PDF by printing to a file so OS is required to provide a printer that outputs to a file. Here's the printcap entry:

file|lp0:\
:ct=dev:\
:lf=/usr/adm/lp0err:\
:lp=/var/spool/output/lp0.out:\
:mx#0:\
:pw#132:\
:rp=text:\
:sd=/var/spool/output:\
:sf:\
:sh:

This does work. 'lpr -Pfile somefile' does put the file contents in var/spool/output/lp0.out. (It does keep appending this file though so I have to make a separate process to copy this lp0 file to a unique file and then clear out lp0 file before printing the next document.)

Tru64 5.1B patch kit 4.

[Michael Schulte zur Sur]

Joe,

I too get the impression that this value is of no use. There is among the open source collection another lprng which has this value too. Maybe you can check into that?

greetings,

Michael

[Siva Kiran Dhulipala]

Hi,
For a local printer, it is lpr that writes into the spooling directory. And lpr doesn't have
intelligence to check the minfree file.

This works for remote printers. If minfree is set in a spooler directory for a printer,
and if there is any request for the printer from a remote host, then lpd checks this file
before putting the control and data files in the spooling directory.

[Michael Schulte zur Sur]

Siva,

I have tried this with an ordinary remote printer and it did not work either.

greetings,

Michael

[Siva Kiran Dhulipala]

Hi Michael,

Probably my understanding of the question might be wrong. I just tried the following.

On a 51B machine say machine1, I created a printer called "local".

On another 51B machine, say machine2, I created a printer called "remote", which is a remote printer to machine1's "local" printer.

now disabled the printing on local (lpc stop local), and created a minfree file in "local"s spool directory (generally I keep /var/spool/printers/printer_name as the spool directory). The number in the minfree is the total number of free blocks in the filesystem.

Now a print request for printer "remote" on machine2 gives a status message: "Tue Nov 8 18:47:25 2005: no space on remote; waiting for queue to drain"

Please let me know if you intend to do this or something else.

-Siva

[Michael Schulte zur Sur · Accepted solution]

Hi Siva,

what you write is interesting and I have checked it on a test machine. The queue on the system where the print job starts says "no space on remote; waiting for queue to drain"
If I understand Joe correctly then he expects a locally executed lpr to also honor the space limit which it does not do. Unfortunately the documentation on the file is not very clear.

greetings,

Michael

[Joe Ledesma]

Hellow Michael and Siva,

Thank you for trying this yourself. I did not know that for local printers it is lpr that does the writing. As you say, Siva, the documentation is not clear on this. lpr(1) says "The lpr command uses the lpd spooling daemon to print files." It refused to print when I temporarily stopped lpd. Also, all the entries in lpr.log are coming from an lpd process. Here are the first few entries.

Nov 8 11:00:01 host lpd[74079]: DEBUG -- lpr - mktemps(): waiting for flock on
.seq file
Nov 8 11:00:01 host lpd[74079]: DEBUG -- lpr - mktemps(): got flock on .seq fi
le
Nov 8 11:00:02 host lpd[74079]: DEBUG -- lpr - about to relock .seq file: /var
/spool/output/.seq
Nov 8 11:00:02 host lpd[74079]: DEBUG -- startdaemon: entered startdaemon(), p
rinter file

--See the attached complete log.

Joe

[Michael Schulte zur Sur]

Joe,

actually lpc status gives the said message.

Michael

[Joe Ledesma]

lpc status does report the said message, but according in the log I got it appears that in general it's lpd that has a routine to write to the status file:

Nov 8 11:00:03 host lpd[74106]: DEBUG -- writeStatus: status file update, printer file: Tue Nov 8 11:00:03 2005: Attempting to print dfA004host

-------------------

Joe