Re: Bug#764253: system-config-printer: Creates millions of ppd symlinks
Hi,
I've also been bitten by this problem:
* systemd-tmpfiles-setup.service hung like forever during boot
* booting from a live system showed that 'ls ./tmp' hangs
* 'ls -U ./tmp | wc -l' showed nearly 2 million files in tmp
* 'find ./tmp -type l -delete' took several hours to delete the links
After that the system could be booted properly again.
Printing from e.g. gedit or evince causes scp-dbus-service to start
creating these links at an insane rate, eating a lot of CPU. This
continues until the scp-dbus-service process is killed.
After that printing doesn't create more links until the next login.
Debugging scp-dbus-service revealed that the problematic part is in
/usr/share/system-config-printer/ppdcache.py, starting at line 136 [1]:
-------------------------------------------------------------------
# Store an open file object, then remove the actual
# file. This way we don't leave temporary files
# around.
try:
self._cache[name] = file (filename)
debugprint ("%s: caching %s (fd %d) "
"(%s) - %s" % (self, filename,
self._cache[name].fileno (),
modtime, status))
os.unlink (filename)
self._modtimes[name] = modtime
except IOError:
# File disappeared?
debugprint ("%s: file %s disappeared? Unable to cache it"
% (self, filename))
-------------------------------------------------------------------
Normally this opens the real file with 'file (filename)' and then
deletes the symlink in /tmp with 'os.unlink (filename)'.
However, if an IOError occurs the symlink is not removed, because it is
assumed to have disappeared.
But on my machine the IOError was actually due to 'Permission denied',
while the symlink existed.
This was caused by the referenced file in /etc/cups/ppd not having
sufficient permissions.
Every <printer>.ppd there had '-rw-r----- 1 root lp' permissions, but
additionally there were also <printer>.ppd.0 files with the correct
'-rw-r--r-- 1 root root' permissions.
After making these ppd files world readable again, the problem vanished:
# chmod -R o+r /etc/cups/ppd
Suspiciously the creation time of these ppd files coincides with the
time at which cups was last triggered by a printer driver update.
Thus I think there are two bugs here:
* cups should not create files with wrong permissions in /etc/cups/ppd
* scp-dbus-service should not start an infinite loop creating millions
of symlinks in /tmp just because the permissions in /etc/cups/ppd
are wrong
Best regards,
Andreas
1:
http://sources.debian.net/src/system-config-printer/1.4.3-4/ppdcache.py/?hl=136#L136
Reply to: