[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Min. Requirement for SKS Version in the Pool
From: |
Daniel Kahn Gillmor |
Subject: |
Re: [Sks-devel] Min. Requirement for SKS Version in the Pool |
Date: |
Mon, 25 Jun 2012 01:41:21 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 |
On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
> Please let me know if we should push the timeline some for the 1.1.2 minimum
> to get more time for testing, as originally stated my primary goal is getting
> to 1.1.3, so this shouldn't necessarily affect too much, we can still keep
> that at August 1.
Another week or two of breathing room for the 1.1.2 limit might be nice,
thanks :)
i believe zimmermann.mayfirst.org is now running 1.1.3, from the
backported debian package.
I ran into two problems during the upgrade:
(0) the post-installation script wants to back up the entire database
before upgrading it from 4.7 to 4.8. This takes a long time and doubles
the amount of space consumed. I think this is a debian-specific issue
(it derives from the packaging's upgrade scripts), so i've filed it at
http://bugs.debian.org/678924.
(1) after the upgrade, some searches caused sks db to hang (hard!) with
the following message written to db.log:
Error fetching uid during VIndex for keyid 0x29BE5D2268FD549F:
Bdb.DBError("unable to allocate memory for mutex; resize mutex region")
I've reported this to debian as well at http://bugs.debian.org/678927,
but i believe this is more of an upstream issue. To resolve the
problem, i terminated both sks processes ("sks db" had to be killed with
SIGKILL once this mutex was hung), copied DB_CONFIG into the PTree and
DB directories, and then restarted the daemons.
This kind of hard hang makes the rest of the service completely
unresponsive. is there some way to improve that behavior upon failure?
I'd rather that the request that exhausts some resource simply fails
with some 500 error code, and allows other (less resource-intensive)
requests to succeed subsequently.
I'll post instructions for migration to 1.1.3 via squeeze-backports once
i'm confident in this setup, and the packaging has migrated into that
repository.
--dkg
signature.asc
Description: OpenPGP digital signature
- [Sks-devel] Min. Requirement for SKS Version in the Pool, Kristian Fiskerstrand, 2012/06/24
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, David Benfell, 2012/06/24
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Brian D Heaton, 2012/06/24
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Daniel Kahn Gillmor, 2012/06/24
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Kristian Fiskerstrand, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, John Clizbe, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Daniel Kahn Gillmor, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, John Clizbe, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Daniel Kahn Gillmor, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Jeffrey Johnson, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Kristian Fiskerstrand, 2012/06/25
- Re: [Sks-devel] Min. Requirement for SKS Version in the Pool, Kristian Fiskerstrand, 2012/06/25