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

Bug#932296: qa.debian.org: getwatch filling up /tmp



On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote:
> On 16/06/20 at 21:07 +0100, Adam D. Barratt wrote:
> > On Tue, 2020-06-16 at 16:40 +0200, Julien Cristau wrote:
> > > On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote:
> > > > Control: severity -1 serious
> > > > 
> > > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote:
> > > > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum
> > > > > wrote:
> > > > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote:
> > > > > > > something in udd seems to extract entire source packages
> > > > > > > to
> > > > > > > /tmp/getwatch.*.  This fills up the disk.  Please make it
> > > > > > > not
> > > > > > > do that.
> > [...]
> > > > This happened again.  If it won't get fixed I'll go ahead and
> > > > disable that job.
> > > > 
> > > Done now, removed the "upstream" importer from the config file.
> > > 
> > 
> > It looks like that wasn't enough, as ullmann filled its disk again.
> > 
> > I've now also updated rudd.conf to disable the importer there.

As a quick note on that, the "disable" key in the configuration doesn't
appear to actually disable anything; from
/srv/udd.debian.org/udd/rlibs/udd-daemon.rb:

def run_importer(imp)
  raise 'bugs importer is special' if imp == 'bugs'
  if imp.has_key?('disabled')
    puts "Not running #{imp['name']}: disabled"
  end
  init_log if not defined?($log)
  $log.debug "Running #{imp['name']}"

So RUDD seems to log that the importer was marked as disabled, and then
run it anyway.

> I emptied the 'upstream' UDD table (no data is better than wrong
> data).
> 
> In a previous message, it was proposed to use temporary space under
> /srv, but /srv only has 3.1 GB left. Could you maybe create a
> /srv/udd.debian.org/tmp with maybe 10G ?
> 
> Also, does DSA offer the service to send icinga notifications to
> service
> owners? Apparently the condition where this happens is quite rare
> occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
> files were cleaned up from /tmp makes it hard to identify which
> packages cause this issue. If I could get notified when a warning
> limit is reached, it would be much easier to debug.

I'm not sure what the usual policy on that is, but I didn't clean up
/tmp after disabling the importer last night:

drwx------ 3 udd     uddadm  4096 Jun 16 20:20 getwatch.qmapshack.n13QHA
drwx------ 3 udd     uddadm  4096 Jun 16 20:20 getwatch.picard-tools.Zg0jud
drwx------ 3 udd     uddadm  4096 Jun 16 20:50 getwatch.qmapshack.aH184l
drwx------ 3 udd     uddadm  4096 Jun 16 20:50 getwatch.picard-tools.SqIkjD
drwx------ 3 udd     uddadm  4096 Jun 16 21:20 getwatch.qmapshack.1pIg10
drwx------ 3 udd     uddadm  4096 Jun 16 21:20 getwatch.picard-tools.g3weib
drwx------ 3 udd     uddadm  4096 Jun 16 21:50 getwatch.qmapshack.oklPSa
drwx------ 3 udd     uddadm  4096 Jun 16 21:50 getwatch.picard-tools.Lo3UhJ

So it looks like it's the same couple of packages over and over.

Regards,

Adam


Reply to: