FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-12-2008, 09:08 PM
Paul Mattal
 
Default Problem with web dashboard: massive orphaning of packages

Dusty Phillips wrote:

2008/9/12 Eric Belanger <belanger@astro.umontreal.ca>:

Hi,

I don't know if you remember but a while ago a huge part of extra i686 (IIRC
it was all packages from L to Z) were orphaned and erroneouly showing up as
recently updated on the web site. This just happened again with packages in
extra x86_64. I don't know what could caused that but it's very annoying as
we has to readopt all our packages back.


Fuck.

I remember Judd telling me not to swear at users but its ok to swear
at scripts right?

This has to be happening in reporead.py. Fucking reporead.py. To the
best of my knowledge, no other script updates the web database in
anyway, am I wrong?


The actual db_update script splits the packages into those that are in
the database and those that are not and processes them separately.
Packages that are not currently in the database get added as orphans
because apparently its hard to interrogate the maintainer from the
db.tar.gz. At first, I assumed that it is doing an add when it should
be doing an update, which would add new packages with orphan
maintainer. But this doesn't appear to be the case because there are
not currently any duplicate x86_64 packages (that aren't in testing).

My second more likely hypothesis is race conditions. I don't know how
the db scripts update exactly, but I suspect reporead is reading a
db.tar.gz file that is either broken or not yet fully uploaded. It
sees this broken db file and drops all the packages in the web
interface that are not in that file. Then x minutes later (crontab),
it runs again on a proper db and sees the missing packages again. It
adds them to the database and sets the maintainer to orphan.

Are such broken dbs possible/likely/happening? If its a race
condition, we need to put a lock on the database (maybe dbtools does
this already) so that reporead isn't accessing it at the same time as
dbtools. If its just that when the database gets updated it sometimes
breaks the database well.. that just needs to be fixed.


Hey, Dusty-- feeling your pain. Don't worry, there's no permanent harm done.

One thing I considered doing with the AUR scripts and might work here is
just setting a threshhold.. if more than X packages seem to be orphaned
since the last run, assume there's an error somewhere, and yell loudly
to several people with root access on the machine.


Even if you set that number really high, this should work-- it's usually
when the whole db is messed up that these sort of bad things happen. It
could check if more than 50% of the packages are being orphaned. A
simple flag to override the check, in the rare case when we really mean
it, would require a simple manual step.


Just a thought.

- P
 
Old 09-12-2008, 09:09 PM
Eric Belanger
 
Default Problem with web dashboard: massive orphaning of packages

On Fri, 12 Sep 2008, Aaron Griffin wrote:


On Fri, Sep 12, 2008 at 2:00 PM, Eric Belanger
<belanger@astro.umontreal.ca> wrote:

Hi,

I don't know if you remember but a while ago a huge part of extra i686 (IIRC
it was all packages from L to Z) were orphaned and erroneouly showing up as
recently updated on the web site. This just happened again with packages in
extra x86_64. I don't know what could caused that but it's very annoying as
we has to readopt all our packages back.


Did it *just* happen, or did it happen last night?




It was happening when I wrote the email. I think it was still happening
after I sent it. I had readopted all my packages by they were all
orphaned again. I guess it was still in the process of readding them or
doing something.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 
Old 09-12-2008, 10:11 PM
Thomas Bächler
 
Default Problem with web dashboard: massive orphaning of packages

Dusty Phillips schrieb:

I think so... not sure if this is a proper test of it but it fails:

dusty:x86_64 $ head -c 10000 extra.db.tar.gz | tar -xz

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

reporead does some great stuff with logger (debug and info). Do you
know if any of those logged messages are saved?


debug and info level messages are saved in /var/log/everything.log.

@Aaron, may I suggest that you add many (all?) devs to the "log" group
so we can read the stuff in /var/log. It is often useful, as it would be
now for Dusty.
 
Old 09-12-2008, 11:12 PM
Alexander Fehr
 
Default Problem with web dashboard: massive orphaning of packages

The x86_64 orphaning has happened again some minutes ago. Moreover, the
i686 packages from extra are now completely gone from the web interface.

Alex
 
Old 09-13-2008, 07:41 AM
Thomas Bächler
 
Default Problem with web dashboard: massive orphaning of packages

Dusty Phillips schrieb:

a) is WTF. I just checked the current state of the db.tar.gz and they
seem to contain packages that reporead claims were removed. So it
doesn't look like anything is breaking the db.tar.gz. It seems more
like reporead is not reading the whole file. But its still possible
the db.tar.gz has been fixed since the error occurred.


Just an idea here: Instead of removing deleted packages from the db, we
could add a "deleted on" column with a date in it. archweb will only
display the lines which have this set to NULL. When we delete a package,
we set this to the current date/time. When we readd a package, all the
maintainer info (and probably other stuff) is still there (as readding
is simply setting the field to "NULL" again). Only when a package has
been deleted for at least 2 weeks, a cleanup script removes it from the
database.


This will save us MUCH trouble next time reporead has a bug like this.
 
Old 09-13-2008, 10:59 AM
Daniel Isenmann
 
Default Problem with web dashboard: massive orphaning of packages

On Sat, 13 Sep 2008 01:12:46 +0200
Alexander Fehr <pizzapunk@gmail.com> wrote:

> The x86_64 orphaning has happened again some minutes ago. Moreover,
> the i686 packages from extra are now completely gone from the web
> interface.
>
> Alex

I would suggest that no developer commit anything or update the db
until this thing is fixed. The complete i686 extra repo is gone from
the web like Alex said it.

Daniel
 
Old 09-14-2008, 08:13 AM
Thomas Bächler
 
Default Problem with web dashboard: massive orphaning of packages

Aaron Griffin schrieb:

On Sat, Sep 13, 2008 at 10:24 AM, Dusty Phillips <buchuki@gmail.com> wrote:

Hey guys,

I tracked down the problem and fixed it. The basic problem is that
there are two packages in i686 right now that have their arch set to
x86_64:

texlive-core
texlive-htmlxml


Looks like the little "hack" of renaming files instead of rebuilding
them bit us in the ass here.
The DB scripts currently look for the arch in the filename, but don't
validate the PKGINFO.


They should. Instead of renaming the file, Francois should have used
makepkg -R with CARCH set to i686.
 

Thread Tools




All times are GMT. The time now is 09:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org