initializedistroseriesjob starved by other jobs

Bug #991876 reported by Colin Watson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
William Grant

Bug Description

When I was initialising Ubuntu quantal, I found that it seemed to be taking a curiously long time to do anything in response to me pushing the button on DistroSeries:+initseries, which I did at 13:45 UTC (timestamps per my IRC client). After twenty minutes or so I asked on #launchpad-ops if anything was happening. At 14:19 UTC, William Grant discovered that soyuz/initializedistroseriesjob.log was saying:

  2012-04-26 14:15:04 DEBUG Lockfile /var/lock/launchpad-jobcronscript.lock in use

This is a rather general lock filename, and it turns out that pofile_stats was holding the lock. William asked webops to disable this job temporarily, and then initializedistroseriesjob was able to proceed. However, it seems suboptimal for this to require operator intervention.

Changed in launchpad:
status: New → Triaged
importance: Undecided → Critical
tags: added: derivation
William Grant (wgrant)
Changed in launchpad:
importance: Critical → High
Revision history for this message
Colin Watson (cjwatson) wrote :

I ran into this again while initialising saucy. The same workaround worked.

Revision history for this message
Colin Watson (cjwatson) wrote :

This appeared to work just fine while opening utopic. Unless somebody specifically recalls fixing this, I suspect we can close this if it still works for V.

Revision history for this message
William Grant (wgrant) wrote :

This was fixed in r16703 when I unified the job runners. process-job-source.py uses a sane lockfile.

Changed in launchpad:
assignee: nobody → William Grant (wgrant)
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.