O pacote sks incluído no Ubuntu 20.04 LTS possui um bug pequeno, mas crítico. Ele insiste em tentar gravar seus arquivos de soquete em/var/run/sks. No entanto, não existe tal diretório. Primeiro de tudo, /var/run foi movido para /run e, segundo, como um tmpfs, /run não teria necessariamente um diretório sks, a menos que tenha sido criado anteriormente.
Por enquanto, resolvi isso criando um serviço extra para sks e sks-recon que simplesmente verifica se /var/run existe, se não, ele vincula /run a /var/run e, em seguida, verifica se /var/run /sks existe e, se não, cria-o e altera seu proprietário para o usuário debian-sks com o qual sks é executado.
Eu apreciaria se alguém pudesse realmente encaminhar tais idéias aos mantenedores do pacote. Levei MUITO tempo para descobrir que um diretório inexistente é o motivo pelo qual o sks continuava reclamando que não conseguia vincular um soquete e que outro processo provavelmente já o tinha feito.
Se valer a pena, aqui está o script rápido que criei. Parece funcionar bem para mim, mas provavelmente poderia ser melhorado.
#!/bin/sh
[ -d /var/run ] || ln -s /run /var/run
if [ ! -d /run/sks ]; then
mkdir /run/sks
chown debian-sks:debian-sks /run/sks
chmod 770 /run/sks ;
fi
e aqui está o arquivo de serviço systemd para iniciá-lo:
[Unit]
Description=Directory Maker for SKS - Work around for bug in SKS code that insists on placing files in /var/run/sks
After=network.target
before=sks.service sks-recon.service
StartLimitIntervalSec=0
[Service]
Type=oneshot
User=root
ExecStart=/var/lib/sks/sksdirmaker.sh
[Install]
WantedBy=multi-user.target
Talvez uma solução feia, mas funciona. Eu testei primeiro garantindo que não houvesse link simbólico /var/run ou diretório /run/sks, então executei: systemctl start sks sks-dirmaker sks-recon
o resultado foi que os diretórios estavam lá e o SKS carregou perfeitamente.