lp:request not accepted

[Rhonda Mokri]

How do we solve the problem of printing a large file on HP-UX 11i? I've checked the normal causes of printing problems and found everything normal - the print spooler is working fine except when dealing with two large files that are over 2.5gb in size.

Is there a size limitation of lp that can be changed?

[skt_skt]

Check if your /var/spool/lp has 2GB free space.

All the requests get queued under /var/spool/lp/request/qname

[Rhonda Mokri]

There is 8.3gb free in /var/spool.

[Eric SAUBIGNAC]

Bonsoir Rhonda,

Don't know if a size limitation exist, and I don't see why it should ...

Where is located the original large file you want to print ? In /var or not ? If not, what is free space in /var ?

Normally the files to be printed are linked into a spool directory /var/spool/lp/.... If linking is not possible, for example because source file is in an other filesystem, the file is copied into the spool directory.

Regards

Eric

[Rhonda Mokri]

The file that the user is trying to print is in one of our application filesystems. I am able to print smaller files just fine from this location but get the lp error when trying to print the 2.5gb file so it is definitely a size related issue. I have split the report into two parts and successfully printed them separately but the user is unhappy with this solution...

[Bill Hassell · Accepted solution]

Your spooler directory is not largefile capable.
Use the command:

df -g /stand | awk '/flags/{print $1,$2}'

This will show something like this:

0x10 flags

or

0 flags

The 0x10 (actually, the 1 digit) indicates that largefiles (larger than 2GB) are enabled on this directory. If not (as in: 0 flags), then no file larger then 2GB can be printed on this system. Change the parent filesystem (probably /var) to support largefiles using fsadm as in:

fsadm -F vxfs -o largefiles /var

For added comfort, you can add the largefiles option to /etc/fstab as in:

/dev/vg00/lvol8 /var vxfs largefiles,nosuid,delaylog 0 2

The above line will check when mounting the filesystem (at boot time) that largefiles has been enabled on /var -- if not, you'll get an error and /var will not be mounted. (see man mount_vxfs or man mount_hfs)

=======================

For the techies:
# filesystem features (from /usr/include/sys/statvfs.h)
# df -g will return these flags
# ST_RDONLY 0x01 /* read only vfs */
# ST_NOSUID 0x02 /* someone is waiting for lock */
# ST_EXPORTED 0x04 /* file system is exported (NFS) */
# ST_QUOTA 0x08 /* filesystem with quotas */
# ST_LARGEFILES 0x10 /* filesystem supports largefiles */

So if flags shows: 0x19 then largefiles is enabled, quotas are enabled and the filesystem was mounted as readonly.

[TTr]

> There is 8.3gb free in /var/spool.

Assuming that /var/spool is the mount point, check if this filesystem has the "largefiles" option turned on.

[Rhonda Mokri]

Thanks!

[skt_skt]

SEP,

enbling the largefiles thorugh fsamd is ONE TIME activity and hence is it mandatory to have the fstab updated.?

We should be OK as long as the same disk is used. Incase of disk failure/replacement the LVM mirror or newfs with largefiles will take care.

[Bill Hassell]

> enbling the largefiles thorugh fsamd is ONE TIME activity and hence is it mandatory to have the fstab updated.?

It does not matter whether the lvol has 8GB or 800GB, unless it has largefiles enabled, no one file can be created larger than 2GB. Yes, the fsadm conversion is a one-time fix (and can be reversed if desired). The fsadm entry is completely optional. As mentioned, the largefiles option is really a check in case the filesystem may have been changed or re-created with nolargefiles.