Re: [Apt-proxy-users] endless recycling

[Chris H. <ha...@de...>]

On Tuesday 25 Jan 2005 11:48, Micha wrote:
> > I run apt-poxy on both my laptop and a server.  I recently moved the
> > cache from the laptop to the server by simply tarring up
> > /var/cache/apt-proxy, transfering it, and then untaring it.  This was a
> > 1.1 gig tranfer.

You should be using the utility written for this purpose, apt-proxy-import.  
If you can arrange to mount the server cache via some means e.g. nfs, you can 
also save network traffic by getting apt-proxy-import to read the server tree 
itself.  That way, it will only copy files that it does not already have in 
its own cache.

> > The problem I'm having is that when apt-proxy starts on the server it
> > spends hours and hours recycling, and whenever apt-proxy restarts, the
> > entire process starts all over again.  

This will be caused by the problems with your database files.

> > Furthermore, I believe that this 
> > recycling is the cause of the "503 Service Unavailable" I receive when I
> > try and access the cache through apt.

That's odd, I don't know what that problem is

> > I used to be able to simply untar .debs into the cache with no problems
> > back when apt-cache was a bash script.  I have two questions.  First,
> > what's causing this?  It looks like a permissions problem, but the
> > permissions look fine.  

I'm not sure. There were some problems with this bit of code and it has been 
recently changed.  Which version of apt-proxy are you running?

> > My second question is why is a this database 
> > needed when it wasn't before

The bash version used to use the filesystem last access time (atime) of the 
file.  This was not very reliable and could be confused by e.g. making copies 
of the cached files (as you are doing on your server), or by using a 
filesystem mounted with noatime.  The database stores these last access times 
in a file under ap's control instead.  If a file is placed in the cache 
without a database entry, you get this 'recycling file' message as apt-proxy 
adds it to its database.

> > , and why does it take 2-3 seconds to recycle 
> > each file?

Because the recycler runs very slowly, sleeping between each cache access.  
Again, using apt-proxy-import is the way to go when mass importing files.

> > 2005/01/15 15:02 CST [-] Starting factory <apt_proxy.apt_proxy.Factory
> > instance at 0x40535b2c> 2005/01/15 15:02 CST [-] set uid/gid 103/65534
> > 2005/01/15 15:02 CST [-] [debug] Verifying database:
> > /var/cache/apt-proxy/.apt-proxy/db/access.db 2005/01/15 15:02 CST [-]
> > [db] /var/cache/apt-proxy/.apt-proxy/db/access.db could not be opened,
> > moved to /var/cache/apt-proxy/.apt-proxy/db/access.db.error 2005/01/15

That indicates the database library could not open the databse, very strange.  
Is it possible you copied that database from the server, and the server has 
different apt-proxy/db library versions?

> > bubbles:/var/cache/apt-proxy/.apt-proxy/db# ls -la
> > total 1764
> > drwx------    2 aptproxy nogroup      4096 Jan 15 15:02 ./
> > drwxr-xr-x    4 aptproxy nogroup      4096 Jul 29 12:10 ../
> > -rw-------    1 aptproxy nogroup    638976 Jan 15 16:35 access.db
> > -rw-------    1 aptproxy nogroup   1318912 Jan 15 04:45 access.db.error
> > -rw-------    1 aptproxy nogroup     12288 Dec  7 21:52
> > access.db.previous -rw-------    1 aptproxy nogroup     45056 Jan 15
> > 04:45 packages.db -rw-------    1 aptproxy nogroup    176128 Dec  7 21:56
> > packages.db.previous -rw-------    1 aptproxy nogroup     12288 Jan 14
> > 10:47 update.db -rw-------    1 aptproxy nogroup     12288 Oct 21 11:29
> > update.db.error -rw-------    1 aptproxy nogroup     12288 Dec  7 21:56
> > update.db.previous

Can you run 'file *' in that directory please?

Chris