Your message dated Mon, 15 Aug 2022 14:36:05 +0100 with message-id <[email protected]> and subject line Re: Bug#826543: cupsd fails to remove job files at end of PreserveJobFiles interval has caused the Debian Bug report #826543, regarding cupsd fails to remove job files at end of PreserveJobFiles interval to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 826543: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826543 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: cups-daemon Version: 1.7.5-11+deb8u1 My /var/spool/cups filled up yesterday. The reason turned out to be that job files had not been purged for the past six days. I'm running with the default setting for PreserveJobFiles (86400 seconds), so this is definitely not intended behaviour. I don't know yet how easy this is to reproduce; the fact that it only started last Tuesday on a system that has been running this version of CUPS for months suggests that it may not be entirely trivial to trigger. Inspection of the source code has led to my spotting a logic flaw in scheduler/job.c:cupsdCleanJobs(). I'm not yet 100% certain that it can account for yesterday's incident, but it is definitely a flaw (apparently still uncorrected in version 2.1.3-5). The flaw is that cupsdCleanJobs() does not consistently guard against the possibility that job->history_time==0 or job->file_time==0 when updating JobHistoryUpdate. On the one hand there are checks like else if (job->file_time && job->file_time <= curtime) and on the other hand one sees, in a different code branch, if (job->file_time < JobHistoryUpdate || !JobHistoryUpdate) JobHistoryUpdate = job->file_time; My impression is that job->file_time can be zero if a job's files have already been cleaned up by remove_job_files(). That could lead to JobHistoryUpdate being 0 on exit from cupsdCleanJobs(), thereby unscheduling further calls to cupsdCleanJobs(). Accordingly, I'd recommend changing the latter statement to if (job->file_time > 0 && (job->file_time < JobHistoryUpdate || !JobHistoryUpdate)) JobHistoryUpdate = job->file_time; and doing something similar to the two statements involving job->history_time. (Aside: CUPS probably won't work very well before 1970-01-01 but I can live with that. I'd be more concerned about INT_MAX being too small.)
--- End Message ---
--- Begin Message ---On Mon 11 Nov 2019 at 16:15:25 +0000, Brian Potkin wrote: [...] > You appear to have the issue under control at your end, so, unless > you wish to take your distinct issue upsteam, I am not sure where we > are going. As far as triaging is concerned, I am not happy to work > on something I cannot reproduce here; it does not make life easy. I am going to assume the issue has been attended to upstream and is no longer a pressing matter with cups 2.4.2-1+b1. Hence closing. Cheers, Brian.
--- End Message ---
