Launchpad itself

bzrsyncd on loganberry using unnecessary amounts of /tmp space

Bug #457026 reported by Tom Haddon
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Please see
 https://pastebin.canonical.com/23612/ and
 https://pastebin.canonical.com/23611/ and
 https://pastebin.canonical.com/41796/
- this is with no currently running processes. Can we simply delete these folders? Why isn't bzrsyncd cleaning them up itself?

See original description
Diogo Matsubara (matsubara)
affects: launchpad → launchpad-code
Tom Haddon (mthaddon)
tags: added: canonical-losa-lp
Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 457026] Re: bzrsyncd on loganberry using unnecessary amounts of /tmp space

random guess: is this obsolete with the removal of the mirrored area?

--
Martin <http://launchpad.net/~mbp/>

Revision history for this message
Curtis Hovey (sinzui) wrote :

Is this still a bug?

Changed in launchpad:
importance: High → Undecided
status: Confirmed → Incomplete
Revision history for this message
Robert Collins (lifeless) wrote :

@poolie loganberry isn't the code hosting server, its where our control scripts and mail processing and other such things run.

Changed in launchpad:
importance: Undecided → High
status: Incomplete → Triaged
description: updated
Revision history for this message
Tom Haddon (mthaddon) wrote :

This is still a bug. Just got disk alerts from loganberry and turns out there's about 20G of /tmp files owned by bzrsyncd.

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 457026] Re: bzrsyncd on loganberry using unnecessary amounts of /tmp space

limbo directories are temporary files. Normally they are cleaned up
before the process exits. I don't know what is causing that to not
happen here. Perhaps the process is terminating abruptly. It would
be nice to investigate, but in the interim I think it would be very
reasonable to turn on tmpwatch on this machine. limbo directories
more than 24h old are I think highly unlikely to be still in use.

I don't know why it is putting them directly in /tmp.

--
Martin

Revision history for this message
Tom Haddon (mthaddon) wrote :

What's preventing investigating this? Do the logs not give us enough info to determine why this might be happening? If not, please let us know and we can adjust logging levels. I think it's reasonable to investigate before resorting to something as messy as manually removing old /tmp files, which will likely mean we never look at this properly.

Revision history for this message
Robert Collins (lifeless) wrote :

We should fix this properly; as volume increases we could in principle
have more content than tmpwatch would handle.

Revision history for this message
Haw Loeung (hloeung) wrote :

FYI, there's a cron job to clean out /tmp/bzr-limbo-* but it would be nice to eventually figure this one out and fix it so that they're cleaned up.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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