[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#826543: marked as done (cupsd fails to remove job files at end of PreserveJobFiles interval)

Your message dated Mon, 15 Aug 2022 14:36:05 +0100
with message-id <15082022143110.b74f09ee78d5@desktop.copernicus.org.uk>
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 owner@bugs.debian.org
immediately.)


-- 
826543: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826543
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 ---
Reply to: