Bug 1048227 - troubleshooter writes huge file into /tmp
Summary: troubleshooter writes huge file into /tmp
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:642e0b3772765a3e0bd2d79c4f3...
: 1050749 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-03 12:51 UTC by collura
Modified: 2014-03-10 10:59 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-08 04:23:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (1.39 KB, text/plain)
2014-01-03 12:51 UTC, collura
no flags Details
File: dso_list (83 bytes, text/plain)
2014-01-03 12:51 UTC, collura
no flags Details
File: environ (2.10 KB, text/plain)
2014-01-03 12:51 UTC, collura
no flags Details


Links
System ID Private Priority Status Summary Last Updated
CUPS Bugs and Features 4366 0 None None None Never

Description collura 2014-01-03 12:51:03 UTC
Description of problem:
printers pingable and discoverable but jobs being held so ran system-config-printer troubleshoot which crashed while in debug phase but kept thinking.  after system-config-printer crashed then abrt wouldnt open.  might have confued it by dismissing the password window that came up for the s-c-p crash report because wasnt sure why it popped up.

Version-Release number of selected component:
system-config-printer-1.4.3-2.fc20

Additional info:
reporter:       libreport-2.1.10
cmdline:        /usr/bin/python /usr/share/system-config-printer/system-config-printer.py
executable:     /usr/share/system-config-printer/system-config-printer.py
kernel:         3.13.0-0.rc6.git0.1.fc21.x86_64
runlevel:       N 5
type:           Python
uid:            0

Truncated backtrace:
ppdcache.py:90:fetch_ppd:IOError: [Errno 28] No space left on device

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/gi/overrides/GLib.py", line 633, in <lambda>
    return (lambda data: callback(*data), user_data)
  File "/usr/share/system-config-printer/asyncipp.py", line 191, in send_reply
    handler (self._conn, result)
  File "/usr/share/system-config-printer/asyncconn.py", line 91, in reply_handler
    self._reply_handler (self, self._reply_data, *args)
  File "/usr/share/system-config-printer/asyncconn.py", line 209, in _subst_reply_handler
    reply_handler (self, *args)
  File "/usr/share/system-config-printer/ppdcache.py", line 58, in <lambda>
    self._got_ppd3 (c, name, r, callback),
  File "/usr/share/system-config-printer/ppdcache.py", line 153, in _got_ppd3
    self.fetch_ppd (name, callback, check_uptodate=False)
  File "/usr/share/system-config-printer/ppdcache.py", line 90, in fetch_ppd
    tmpf.writelines (f.readlines ())
IOError: [Errno 28] No space left on device

Local variables in innermost frame:
name: u'<removed>'
f: <open file '/tmp/52c68070b65b5', mode 'r' at 0x1308ed0>
check_uptodate: False
self: <ppdcache.PPDCache instance at 0x1897518>
tmpf: <open file '/tmp/tmpWAxKdB', mode 'w' at 0x45594b0>
tmpfd: 18
callback: <bound method StateReason._got_ppd of <statereason.StateReason (REPORT,<removed>,offline-report)>>
tmpfname: '/tmp/tmpWAxKdB'

Comment 1 collura 2014-01-03 12:51:12 UTC
Created attachment 844949 [details]
File: backtrace

Comment 2 collura 2014-01-03 12:51:14 UTC
Created attachment 844950 [details]
File: dso_list

Comment 3 collura 2014-01-03 12:51:18 UTC
Created attachment 844951 [details]
File: environ

Comment 4 Tim Waugh 2014-01-03 16:01:30 UTC
What does 'df -h' say?

It looks like you're out of disk space in /tmp. In a default installation, this is a tmpfs file system and so is limited in space.

Comment 5 collura 2014-01-04 09:26:23 UTC
hi, yes thanks i had found that /tmp was full after filed but hadnt had a chance to update yet :') 

system-config-printer troubleshoot seems to write large (multiple gigabytes) amounts of data to /tmp and /var/log/cups/*_log .

if i clean out the /tmp file the /tmp is at about 1percent usage before run system-config-printer (df says that /tmp is alotted 2.7GB, all of which gets eaten when run system-config-printer troubleshoot) but when i run system-config-printer troubleshoot the file keeps growing until /tmp grows to 100percent usage and then the system-config-printer dialog keeps going but abrt reports that system-config-printer has crashed (so i hit report) and then abrt promptly crashes for same loss of /tmp space reason (until i remove the /tmp file i cant get abrt to launch).

(for different bug report when i organize but fyi: 
printer is lexmark ms3xx series and have installed lexmark supplied the GlobalPPD_1.4 ppd file manually to /usr/share/ppd/cupsfilters and when configure printer just browse to that file. periodically i am able to print a test page but only sometimes and cant get a editor program to actually print. the jobs either process indefinintely saying something like printer offline or say held.)

Comment 6 Tim Waugh 2014-01-09 13:06:27 UTC
*** Bug 1050749 has been marked as a duplicate of this bug. ***

Comment 7 Tim Waugh 2014-01-09 13:08:48 UTC
Of course, if the "journal" log target was enabled by default, we could simply use the journal API to fetch the log for the job in question...

Comment 8 Tim Waugh 2014-02-11 17:02:22 UTC
I've just filed STR #4366 upstream, which is relevant to this bug.

Comment 9 collura 2014-03-08 04:23:22 UTC
cups-1.7.1-6.fc20.x86_64 (to address infinite loops, etc) in updates-testing:

"http://koji.fedoraproject.org/koji/buildinfo?buildID=502856
Changelog 	* Thu Mar 06 2014 Tim Waugh <twaugh> - 1:1.7.1-6 - Track local default in cupsEnumDests() (STR #4332). - libcups: avoid race condition when sending IPP requests (STR #4386). - Prevent feedback loop when fetching error_log over HTTP (STR #4366). * Wed Mar 05 2014 Tim Waugh <twaugh> - 1:1.7.1-5 - Fix for cupsEnumDest() 'removed' callbacks (bug #1054312, STR #4380)."

fixed the giant file issue for me, closing.

thanks :')

Comment 10 Tim Waugh 2014-03-10 10:59:11 UTC
Oh yes, thanks. For the record, this update was:
https://admin.fedoraproject.org/updates/FEDORA-2014-3451


Note You need to log in before you can comment on or make changes to this bug.