On 10/17/2020 9:00 AM, Adam Wojcieszonek wrote: > Hi Todd, > Last 4 days I'm reading all threads with sks tunning, suggestions / > troubles / errors etc.. It's really large dose of valuable informations. > SKS gives me different surprises every day. Final tunning its one of > most important thing but it's very difficult to prevent malfunctions > with unknown reasons. Today new one again - SKS shutting down every > few hours. When restarting manually, situation repeats itself after > few hours. > > sks.service - SKS database service > Loaded: loaded (/lib/systemd/system/sks.service; enabled; vendor > preset: disabled) > Active: failed (Result: signal) since Sat 2020-10-17 15:55:14 CEST; > 22min ago > Docs: man:sks(8) > Process: 3474 ExecStart=/usr/sbin/sks -stdoutlog db (code=killed, > signal=SEGV) > Main PID: 3474 (code=killed, signal=SEGV) > > Oct 17 15:55:14 Khaos systemd[1]: sks.service: Main process exited, > code=killed, status=11/SEGV > Oct 17 15:55:14 Khaos systemd[1]: sks.service: Failed with result > 'signal'. > > Keeping keys on servers like sks is a very important goal for a > positive idea but costs much work and attention. > > br > > Adam
Are you always getting status=11/SEGV? Because if you are you have a major problem with your sks binary. SEGV = Segmentation Fault, what was also known as an Access Violation or an Invalid Page Request in the old Windows 9x days. Sorry for coming in late on this one, but what OS are you using SKS on? And if Linux, what Distro? Custom compiled or Distro package? -- Dan Egli On my Test server
OpenPGP_0xF8A7B3F2AAB08F9D.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
