cups leaves a 0 size file in /var/spool/cups/tmp/ this happens since at least cups 1.14 ~]# ls -lstrAF /var/spool/cups/tmp/|head -22 total 2784 4 -rw------- 1 lp sys 0 Jan 5 18:01 gs_Os5qDi 4 -rw------- 1 lp sys 0 Jan 5 18:01 gs_7Zfimi 4 -rw------- 1 lp sys 0 Jan 5 18:14 gs_ZOOEAx 4 -rw------- 1 lp sys 0 Jan 5 18:14 gs_of989O 4 -rw------- 1 lp sys 0 Jan 5 18:34 gs_sMpwLA 4 -rw------- 1 lp sys 0 Jan 5 18:34 gs_5PONTK 4 -rw------- 1 lp sys 0 Jan 5 19:08 gs_6Z9MCH 4 -rw------- 1 lp sys 0 Jan 5 19:08 gs_3HzOVE 4 -rw------- 1 lp sys 0 Jan 5 22:09 gs_Un0nyR 4 -rw------- 1 lp sys 0 Jan 5 22:09 gs_e9nH7v 4 -rw------- 1 lp sys 0 Jan 5 22:09 gs_DyeNgx 4 -rw------- 1 lp sys 0 Jan 5 22:09 gs_3yzZPb 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_vyTcSK 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_vkOB6f 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_upWXVW 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_U37O2O 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_RwH78C 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_PxXNLn 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_p2B3Yn 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_MVFXkz 4 -rw------- 1 lp sys 0 Jan 5 22:14 gs_mGYDKj ... and 3000 other 0 length files
I don't see this here. Please show me the output of these commands (as root): rpm -q cups rpm -V cups
I have regular cups with no changes connected to HP 1300 PCL. Same problem exists since at least RedHat 7 [root@localhost ~]# rpm -q cups cups-1.1.22-0.rc1.8.3 [root@localhost ~]# rpm -V cups .M....... /etc/cups S.5....T. c /etc/cups/cupsd.conf S.5....TC c /etc/cups/printers.conf .M....... /var/spool/cups/tmp [root@localhost ~]#
cat /etc/cups/printers.conf # Printer configuration file for CUPS v1.1.22rc1 # Written by cupsd on Wed 05 Jan 2005 06:00:44 PM EST <DefaultPrinter pp> Info HP 1200 Location 118 DeviceURI parallel:/dev/lp0 State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 </Printer> # head -22 /etc/cups/ppd/pp.ppd *PPD-Adobe: "4.3" *%PPD file for CUPS/Gimp-Print. *%Copyright 1993-2001 by Easy Software Products, All Rights Reserved. *%This PPD file may be freely used and distributed under the terms of *%the GNU GPL. *FormatVersion: "4.3" *FileVersion: "4.2.7" *LanguageVersion: English *LanguageEncoding: ISOLatin1 *PCFileName: "STP00228.PPD" *Manufacturer: "HP" *Product: "(AFPL Ghostscript)" *Product: "(GNU Ghostscript)" *Product: "(ESP Ghostscript)" *ModelName: "HP LaserJet 5 series" *ShortNickName: "HP LaserJet 5 series" *NickName: "HP LaserJet 5 series - CUPS+Gimp-Print v4.2.7" *PSVersion: "(2017.000) 550" *LanguageLevel: "2" *ColorDevice: False *DefaultColorSpace: Gray *FileSystem: False
Created attachment 109919 [details] cups log cups printing log. Two files in /var/spool/cups/tmp/ were created 4 -rw------- 1 lp sys 0 Jan 18 06:17 gs_tPmPtM 4 -rw------- 1 lp sys 0 Jan 18 06:17 gs_oJzssn
This is interesting: .M....... /var/spool/cups/tmp It means that the file mode is different now compared to when it was installed. Well, what does this say?: ls -ld /var/spool/cups/tmp It should say this: drwxrwx--T 2 root sys 4096 Jan 17 15:13 /var/spool/cups/tmp If not then that's why. (By the way, CUPS first shipped with Red Hat Linux 9.)
[root@localhost ~]# ls -ld /var/spool/cups/tmp drwxrwx--T 2 root sys 16384 Jan 18 06:17 /var/spool/cups/tmp may be something is wrong with selinux attributes [root@localhost ~]# ls -ldZ /var/spool/cups/tmp drwxrwx--T root sys system_u:object_r:var_spool_t /var/spool/cups/tmp >(By the way, CUPS first shipped with Red Hat Linux 9.) yes, but back then up2date -u replaced my LPRnG by cups, which screw printing. I left cups since then. I think it was a mismanagement of up2date repositories.
Run this command: restorecon -v /var/spool/cups/tmp (SELinux certainly didn't ship with Red Hat Linux 7!)
Same thing: [root@localhost ~]# restorecon -v /var/spool/cups/tmp [root@localhost ~]# rpm -V cups .M....... /etc/cups S.5....T. c /etc/cups/cupsd.conf S.5....TC c /etc/cups/printers.conf .M....... /var/spool/cups/tmp ls -ldZ /usr/lib/cups/filter/pstops /usr/lib/cups/filter/pstoraster /usr/lib/cups/filter/rastertoprinter /usr/lib/cups/backend/parallel /usr/bin/gs -rwxr-xr-x root root system_u:object_r:bin_t /usr/bin/gs -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/cups/backend/parallel -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/cups/filter/pstops -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/cups/filter/pstoraster -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/cups/filter/rastertoprinter
[root@localhost ~]# restorecon -v /var/spool/cups/tmp [root@localhost ~]# ls -ldZ /var/spool/cups/tmp drwxrwx--T root sys system_u:object_r:var_spool_t /var/spool/cups/tmp
may be it is somehow related to gimp-print. I am using HP LaserJet 5 series - CUPS+Gimp-Print v4.2.7 for printing. (needs gimp-print-cups-4.2.7-2 )
I modified pstoraster to check what gs does (see below) The files left in /var/spool/cups/tmp/ are 4 -rw------- 1 lp sys 0 Jan 18 15:01 gs_LJrtg6 4 -rw------- 1 lp sys 0 Jan 18 15:01 gs_HroCXW Because now I have gs's strace stderr in /tmp/serr relevant tmp files can be obtained as grep /var/spool/cups/tmp /tmp/serr TMPDIR=/var/spool/cups/tmp open("/var/spool/cups/tmp/gs_LJrtg6", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 open("/var/spool/cups/tmp/gs_HroCXW", O_RDWR|O_CREAT|O_EXCL, 0600) = 7 open("/var/spool/cups/tmp/gs_fxxZEN", O_RDWR|O_CREAT|O_EXCL, 0600) = 8 open("/var/spool/cups/tmp/gs_pGdqmE", O_RDWR|O_CREAT|O_EXCL, 0600) = 9 open("/var/spool/cups/tmp/gs_fxxZEN", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8 open("/var/spool/cups/tmp/gs_fxxZEN", O_RDWR|O_CREAT|O_TRUNC, 0666) = 8 open("/var/spool/cups/tmp/gs_pGdqmE", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9 open("/var/spool/cups/tmp/gs_pGdqmE", O_RDWR|O_CREAT|O_TRUNC, 0666) = 9 open("/var/spool/cups/tmp/gs_fxxZEN", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8 open("/var/spool/cups/tmp/gs_fxxZEN", O_RDWR|O_CREAT|O_TRUNC, 0666) = 8 open("/var/spool/cups/tmp/gs_pGdqmE", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9 open("/var/spool/cups/tmp/gs_pGdqmE", O_RDWR|O_CREAT|O_TRUNC, 0666) = 9 unlink("/var/spool/cups/tmp/gs_fxxZEN") = 0 unlink("/var/spool/cups/tmp/gs_pGdqmE") = 0 It is easy to see that /var/spool/cups/tmp/gs_LJrtg6 /var/spool/cups/tmp/gs_HroCXW were created, but there is no unlink on them. Looks like a bug in gs. Looks pretty much like that very bug from RedHat 7. P.S. what I modified diff pstoraster.SAVE1 pstoraster 55,56c55,60 < $bindir/gs $gsopts -sOUTPUTFILE="%stdout" $profile $ifile < --- > { > set -x > set > strace $bindir/gs $gsopts -sOUTPUTFILE="/tmp/jj.ps" $profile $ifile > }>/tmp/serr 2>&1 > exit ---------- stderr beginning head -70 /tmp/serr + set BASH=/bin/sh BASH_ARGC=([0]="5") BASH_ARGV=([0]="" [1]="1" [2]="(stdin)" [3]="mal" [4]="213") BASH_LINENO=([0]="0") BASH_SOURCE=([0]="/usr/lib/cups/filter/pstoraster") BASH_VERSINFO=([0]="3" [1]="00" [2]="14" [3]="1" [4]="release" [5]="i386-redhat-linux-gnu") BASH_VERSION='3.00.14(1)-release' CHARSET=utf-8 CONTENT_TYPE=application/postscript CUPS_DATADIR=/usr/share/cups CUPS_FONTPATH=/usr/share/cups/fonts CUPS_SERVER=localhost CUPS_SERVERROOT=/etc/cups DEVICE_URI=parallel:/dev/lp0 DIRSTACK=() EUID=4 GROUPS=() GS_FONTPATH=/usr/share/cups/fonts HOSTNAME=localhost.localdomain HOSTTYPE=i386 IFS=' ' IPP_PORT=631 LANG=en_US MACHTYPE=i386-redhat-linux-gnu OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/lib/cups/filter:/bin:/usr/bin PIPESTATUS=([0]="0") POSIXLY_CORRECT=y PPD=/etc/cups/ppd/pp.ppd PPID=11271 PRINTER=pp PS4='+ ' PWD=/ RIP_MAX_CACHE=8m SHELL=/sbin/nologin SHELLOPTS=braceexpand:hashall:interactive-comments:posix:xtrace SHLVL=1 SOFTWARE=CUPS/1.1 TERM=dumb TMPDIR=/var/spool/cups/tmp UID=4 USER=root _=-x bindir=/usr/bin exec_prefix=/usr gsopts='-dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr' ifile=- prefix=/usr profile= + strace /usr/bin/gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=/tmp/jj.ps - execve("/usr/bin/gs", ["/usr/bin/gs", "-dQUIET", "-dDEBUG", "-dPARANOIDSAFER", "-dNOPAUSE", "-dBATCH", "-dNOMEDIAATTRS", "-sDEVICE=cups", "-sstdout=%stderr", "-sOUTPUTFILE=/tmp/jj.ps", "-"], [/* 20 vars */]) = 0 uname({sys="Linux", node="localhost.localdomain", ...}) = 0 brk(0) = 0x9cf3000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
What file did you print?
any postscript file. Say print in firefox this bug report.
Created attachment 110026 [details] test to obtain 0 length files 1. go to cd /tmp/ 2. run as root tst.sh the results: [root@localhost tmp]# sh -x tst.sh + set -x + cd /tmp + cat gsin.ps + strace /usr/bin/gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=/tmp/sout.sout -sOUTPUTFILE=/tmp/jj.pcl - + ls -l gs_zhxSKf gs_EIzkmy 4 -rw------- 1 root root 0 Jan 20 14:20 gs_zhxSKf 4 -rw------- 1 root root 0 Jan 20 14:20 gs_EIzkmy
Okay, I see that here too. I'm going to add a cron job to the cups package to clean out unused files in the spool temporary directory. I'll keep this bug report open to track the ghostscript problem of leaving the temporary files lying around in the first place. Thanks for the test case.
Why to cups package? May be to tmpwatch , file /etc/cron.daily/tmpwatch In the same time the bug with 0 length files is probably very easy to fix in gs. Once the contact with the gs people is established - it would take probably less then 10 minutes for them to fix.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Has this bug been fixed in Fedora 8?
Fedora Core 3 is not maintained anymore. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release please reopen this bug.