Univention Bugzilla – Bug 51605
cleanup /var/cache/univention-printserver/ after release update
Last modified: 2022-09-08 12:23:07 CEST
+++ This bug was initially created as a clone of Bug #40904 +++ Seen in several customer environments. Somehow some old printer change commands survived in the cups command cache /var/cache/univention-printserver/, e.g. /var/cache/univention-printserver/1437651522.287814.sh /usr/sbin/univention-lpadmin '-u' 'allow:all' '-o' 'auth-info-required=none' '-p' 'printer1' '-m' 'postscript/Kyocera/es/Kyocera_Mita_FS-1900_es.ppd.gz' '- v' 'socket://10.15.1.1:9100' '-E' The ppd 'postscript/Kyocera/es/Kyocera_Mita_FS-1900_es.ppd.gz' is totally outdated and lpadmin fails. During start of /etc/init.d/cups these commands are executed and removed if successful, but as the ppd is outdated and lpadmin fails, the command above never gets removed but restarted every time executed the cupsd is (re)started. Now somebody makes a change on printer1 (activates quota, changes ip address), after some time cups is restarted and the command cache executed. Although the command in the cups cache fails, it still reverts some changes of printer1. We may need to cleanup /var/cache/univention-printserver/ at some point. Not sure when. Ticket 2016030807000045 Ticket 2016031421000328
One of the first customers reports the problem today. Due to years of using UCS, various "corpses" have accumulated, which (want to) set outdated configurations. Details see Ticket
One of our customers reported that even if the lpadmin command fails, some printer settings might get changed or printers get recreated. And since the files in /var/cache/univention-printserver/ do not get removed automatically, manual changes to printers are regulary overwritten resp. unwanted printers get recreated every time when cups is restarted (→ logrotate). Reported again by the same customer as in ticket 2020070121000506.
Maybe we should implement a diagnosis module that warns about these files?
Still an everyday PITA here.... Maybe this could be solved when support for driverless printing support is (hopefully) added to UCS? On the LDAP side it would be as simple as the last comment in this bug, we already use that "hack": https://forge.univention.org/bugzilla/show_bug.cgi?id=51681 It would probably just require some adjustments and better error handling to the cups-printers listener module.