Open larsw opened 6 years ago
Sorry for the late response but I just noticed this issue. I'm working on a revision to the image currently that should hopefully remove the need to run the sks-init
script as the new ENTRYPOINT
for the image will automatically attempt to import the key dump contents if the key database (/var/lib/sks/KDB) doesn't and there is an available key dump available under /data/dump
. My decision to read the dump from outside of the /var/lib/sks
base directory is in an attempt to keep from having SKS open all the files when launching after importing. I'm doing a lot of testing on this currently and have not yet pushed the changes up to the repository. When I do the jtbouse/sks
image on Docker Hub will also be updated.
As to the errors your log is displaying, I am not precisely sure to the cause but I had been having some database corruption issues with my own SKS keyserver running the image so I can't rule out the possibility it is related to that. The sks-log-clean
service does attempt to run db_archive
against the key and ptree databases on starup and as uploaded every 7 days though I'm changing that to every 2 hours to try and keep the BDB logs from getting too out of control as I saw them doing sometimes.
Another side effect of the way I had this image startup sequenced the s6 supervision was attempting to perform it's tasks before forking off the shell to execute the sks-init
so it's possible this is where the conflict is coming from. The new ENTRYPOINT should remediate this situation as well as providing any options to the command will simply in effect ignore the s6 supervision.
Any idea what this is caused by? I've run sks-init on the volume bound to /var/lib/sks ...