bzrsyncd on loganberry using unnecessary amounts of /tmp space

Bug #457026 reported by Tom Haddon on 2009-10-21
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
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?

affects: launchpad → launchpad-code
Tom Haddon (mthaddon) on 2010-05-28
tags: added: canonical-losa-lp

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

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

Curtis Hovey (sinzui) wrote :

Is this still a bug?

Changed in launchpad:
importance: High → Undecided
status: Confirmed → Incomplete
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
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.

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

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.

Robert Collins (lifeless) wrote :

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

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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers