DB size when using "build"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DB size when using "build"

Michael Gurski
Out of curiosity, what are current DB sizes when building the key db
with "build" as opposed to "fastbuild"?  I'm currently trying to
estimate when this build will finish on the new system, though space
itself isn't a concern.

Also, for those syncing with keyserver.gurski.org, it should be back up
once the build's done.  Major badness with hardware this past weekend
blew away my plans to silently transition to a new server @ the same
address (via an internal sync between the former sks install and this
new one).  Instead, I'm having to go "from scratch", and just managed to
figure out how to get the Debianized SKS to build properly on amd64 last
evening...

--
Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
Views expressed by the host do not reflect the staff, management or sponsors.

"No man is good enough to govern another man without that other's
consent."  --Abraham Lincoln

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Segmentation fault is sks pbuild

Michael Gurski
On Thu, Nov 17, 2005 at 02:08:49PM -0500, Michael Gurski wrote:
> Also, for those syncing with keyserver.gurski.org, it should be back up
> once the build's done.  Major badness with hardware this past weekend
> blew away my plans to silently transition to a new server @ the same
> address (via an internal sync between the former sks install and this
> new one).  Instead, I'm having to go "from scratch", and just managed to
> figure out how to get the Debianized SKS to build properly on amd64 last
> evening...

Apparently I spoke too soon.  I'm getting segfaults when I try to
pbuild.  Running sks with strace, it seems to bomb out in in mremap, and
a backtrace on the core yields:

(gdb) where
#0  0x00002aaaaae302a1 in __db_tas_mutex_lock_4001 () from
/usr/lib/libdb-4.1.so
#1  0x00002aaaaaea68a0 in __memp_fget_4001 () from /usr/lib/libdb-4.1.so
#2  0x00002aaaaae3cf73 in __bam_c_dup_4001 () from /usr/lib/libdb-4.1.so
#3  0x00002aaaaae40286 in __bam_c_rget_4001 () from
/usr/lib/libdb-4.1.so
#4  0x00002aaaaae5f276 in __db_c_get_4001 () from /usr/lib/libdb-4.1.so
#5  0x00000000004d8e2a in bzero ()
#6  0x00000000004ed5cc in bzero ()

I've been googling for berkeley db4.1 problems, but haven't been able to
find anything.  Has anyone seen this before on an AMD64?

--
Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
Views expressed by the host do not reflect the staff, management or sponsors.

"It violates right order whenever capital so employs the working or
wage-earning classes as to divert business and economic activity
entirely to its own arbitrary will and advantage, without any regard
to the human dignity of the workers, the social character of economic
life, social justice, and the common good."  --Pope Pius XI

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation fault is sks pbuild

Michael Gurski
On Fri, Nov 18, 2005 at 12:35:44AM -0500, Michael Gurski wrote:

> Apparently I spoke too soon.  I'm getting segfaults when I try to
> pbuild.  Running sks with strace, it seems to bomb out in in mremap, and
> a backtrace on the core yields:
>
> (gdb) where
> #0  0x00002aaaaae302a1 in __db_tas_mutex_lock_4001 () from
> /usr/lib/libdb-4.1.so
> #1  0x00002aaaaaea68a0 in __memp_fget_4001 () from /usr/lib/libdb-4.1.so
> #2  0x00002aaaaae3cf73 in __bam_c_dup_4001 () from /usr/lib/libdb-4.1.so
> #3  0x00002aaaaae40286 in __bam_c_rget_4001 () from
> /usr/lib/libdb-4.1.so
> #4  0x00002aaaaae5f276 in __db_c_get_4001 () from /usr/lib/libdb-4.1.so
> #5  0x00000000004d8e2a in bzero ()
> #6  0x00000000004ed5cc in bzero ()
>
> I've been googling for berkeley db4.1 problems, but haven't been able to
> find anything.  Has anyone seen this before on an AMD64?
Nevermind, I found it.  Out of desperation, I started mucking with
various ulimit settings to see if they had any effect.  As most were
already "unlimited", I had open files, pipe size, and stack size to
choose from.  Apparently what was happening was sks was blowing its
stack, as doubling the stacksize limit (from 8192 to 16384) allowed
pbuild to run to completion without any problems.

So, uh, yay desperation?


--
Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
Views expressed by the host do not reflect the staff, management or sponsors.

"The ideas which now pass for brilliant innovations and advances are
in fact mere revivals of ancient errors, and a further proof of the
dictum that those who are ignorant of the past are condemned to repeat
it."  --Henry Hazlitt

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Segmentation fault is sks pbuild

Daniel Johnson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Gurski wrote:
 > Nevermind, I found it.  Out of desperation, I started mucking
 > with various ulimit settings to see if they had any effect.  As
 > most were already "unlimited", I had open files, pipe size, and
 > stack size to choose from.  Apparently what was happening was sks
 > was blowing its stack, as doubling the stacksize limit (from
 > 8192 to 16384) allowed pbuild to run to completion without any
 > problems.
 >
 > So, uh, yay desperation?

'tis the mother of invention.  :)

Daniel Johnson
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDfeVu6vGcUBY+ge8RAn+WAKClyfq3uVPqekraFOOfIoctJR2BmACeOHFo
TC5uUg69pJPdTrHg7V6m6AI=
=WFIo
-----END PGP SIGNATURE-----


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel