All right, those were really good tips - the build actually looks like it's working now (since I get the expected output).
The sks_build.sh script contains further actions: echo "=== Running (fast)build... ===" if ! /usr/sbin/sks $mode -n 12 -cache 100; then fail; fi echo === Cleaning key database... === if ! /usr/sbin/sks cleandb; then fail; fi echo === Building ptree database... === if ! /usr/sbin/sks pbuild -cache 20 -ptree_cache 70; then fail; fi echo === Done! === Am I right when assuming that I need to run # /usr/sbin/sks cleandb and then # /usr/sbin/sks pbuild -cache 20 -ptree_cache 70 after this build step? And are the cache options in the pbuild step OK? I'm on a steep learning curve here... :-) Humbly, A 2012/9/9 John Clizbe <[email protected]> > Andreas Thulin wrote: > > My bad, I sent my e-mail to the wrong receiver... > > > > Also, a correction: I'm running sks version 1.1.3. > > > > Please see below. > > > > /A > > > > 2012/9/9 Andreas Thulin <[email protected] > > <mailto:[email protected]>> > > > > Hi! > > > > I'm running Ubuntu 12.04 (64 bit) on an Asrock Ion 3D > > ( > http://www.asrock.com/nettop/overview.asp?Model=ION%203D%20Series#Specifications > ), > > 2Gb RAM. > > > > SKS version 1.1 > > Berkeley version: ? - How do I find out? > > > > I'm running a fastbuild (n=1), which seemed to work for a qouple of > > minutes, but then it looked like it stopped. > > > > Running > > # strace -p processID > > first gave a lot of reads, but then has produced nothing but > > > > futex(0x7f0c1db15358, FUTEX_WAIT, 2, NULL > > > > the last 10 hours. > > > > The funny thing is that something writes to the /sks/DB directory > every > > now and then. It seems to happen each time I run strace, but also at > other > > times. I'm thinking maybe the "n=1" thing makes this fastbuild very > slow, > > and the process hence should take several hours still. > > For a variety of reasons mostly personal, I have never used fastbuild only > build. n for fastbuild is the multiple of 15000 keys to load on a single > pass, > For build, n is the number of key files to read in per pass. Depending on > which keydump you are using, the two may effectively be the same as 15000 > is > the default number of keys to dump per file. I use n=14 (210000 keys) on my > gingerbear machine which is the same hardware as the Windows XP box > mentioned > below, it runs Slackware-current. > > In /etc/sks, you should have a file named sksconf. Add the following two > lines > > pagesize: 128 > ptree_pagesize: 8 > > The default value for pagesize is 4 (2048 bytes) and for PTree it's 1 (512 > bytes). Experience has shown these to be too low. The defaults are > adjusted in > the trunk version. > > Make that change, stop the (fast)build. Delete any directories in > /var/sks/lib > and try again. I'd use something like: > > sks build -n 12 -cache 100 /var/sks/dump/*.pgp > > or similar or use the build script that ships with Debian. > > > What amount of time should I expect this to take? > > I last built a SKS database on a Windows XP box (Athlon XP 2800+, 2.13GHz; > 2GB > RAM, PATA/133 drives) back on 25 July. Times were > > build: 4:18:39.734 > clean: 0:03:31.031 > pbuild: 1:12:11.641 > > That was a build with n=5. n is adjusted on each machine to a value that > does > not cause swapping to occur. build depends more on the speed of your disks > than anything else. > > > Running this DB build with some sort of human readable periodic > progress > > indication is of course preferrable. > > When I run build, I get the output like: > > Build > Wed, Jul 25, 2012 1:15:51 AM > Loading keys...done > DB time: 2.95 min. Total time: 4.74 min. > Loading keys...done > DB time: 4.88 min. Total time: 6.74 min. > Loading keys...done > DB time: 3.69 min. Total time: 5.28 min. > Loading keys...done > DB time: 3.78 min. Total time: 5.29 min. > Loading keys...done > etc... > > The first two lines are from my build script. clean and pbuild both have > their > own log files that you can follow with 'tail -f'. clean.log tells you what > actions it is performing. pbuild.log spits out a timestamp every 5000 > hashes > it processes. > > > Thanks all for helpful pointers! :-) > > No problem. You're welcome. > > > Best regards, > > Andreas > > Good luck. > -John > -- > > John P. Clizbe Inet: John (a) Gingerbear DAWT net > SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net > FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or > mailto:[email protected]?subject=HELP > > Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" > A:"An odd melody / island voices on the winds / surplus of vowels" > > > > _______________________________________________ > Sks-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/sks-devel > >
_______________________________________________ Sks-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/sks-devel
