Re: [Sks-devel] keyserver.linux.it is changing IP

[Marco Nenciarini]

On 26/01/2011 07:37, Marco Nenciarini wrote:
> On 26/01/2011 01:21, Victor Escudero Rubio wrote:
>> Hi Marco,
>>  
>> It seems that the PTree DB is corrupted. I imagine that you have already 
>> tried 
>> to recreate it, Don't you?
>>
> 
> The problem is exactly that PTree db is corrupted. The weird thing is
> that it's freshly generated from a brand new KDB.
> 
>> After building the database I would try to do a cleaning:  '/usr/sbin/sks 
>> cleandb'; 
>> then I would remove the PTree DB with 'rm /var/lib/sks/PTree' 
>> and recreate it with something like: '/usr/sbin/sks pbuild -cache 20 
>> -ptree_cache 70'
>>
> 
> For every try I've mentioned in previous message I've generated the KDB
> with build or fastbuild, I've cleaned it with cleandb, then I've
> generated PTree with "sks pbuild -cache 20  -ptree_cache 70" (but I've
> also tried with other cache values, just to be sure)
> 
>> At last be careful with the ownership of the files as they should be chown 
>> to 
>> debian-sks with 'chown -R debian-sks:debian-sks /var/lib/sks/'
> 
> I've also tried both runing build/pbuild commands as root to fix
> permissions after the database were built and running them directly with
> debian-sks user. I've also tried running it with "mnencia" user in a
> different directory without lucky.
> 
> I'm quite sure it isn't a problem of db_env, because I've tried to run
> several db_recover (with or without the -e flag) and db_checkpoint -1.
> 
> I can also assure you that it isn't a memory problem, because the server
> is a virtual machine that lives in a blade server with checked memory.
> 
> I'm at my wits' end.
> 

I've totally excluded a problem in dependency, because I've tried to
build and run the exactly same version I've been running on old server
in an etch chroot (exactly same distribution), and the instantly PTree
corruption on the very first run is still there.

So I think it's more an "environmental" issue. The old machine was very
different to the new one. Beside the 32/64 bit difference (which
probably isn't influent because I've tried to run sks with both), the
former machine was a real one with 4Gb of ram, real disks and only one
processor. The latter is a a XEN VM with the same amount of ram, all
disks mounted from a SAN via iSCSI protocol and two processors. Moreover
the linux kernel is different, as the former was running the default
etch one and the latter is running the default Lenny one (as provided by
its dom0)

Do someone see how these difference can lead to a PTree corruption
during (at least) the pbuild run?

Thanks in advance,
Marco

-- 
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| address@hidden | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4

signature.asc
Description: OpenPGP digital signature