El paquete sks incluido en Ubuntu 20.04 LTS tiene un error pequeño pero crítico. Insiste en intentar escribir sus archivos de socket en /var/run/sks. Sin embargo, no existe tal directorio. En primer lugar, /var/run se movió a /run y, en segundo lugar, como tmpfs, /run no necesariamente tendría un directorio sks a menos que se haya creado previamente.
Por ahora he solucionado esto creando un servicio adicional para sks y sks-recon que simplemente verifica si /var/run existe, si no, vincula simbólicamente /run a /var/run, luego mira para ver si /var/run /sks existe y, si no, lo crea y cambia su propietario al usuario debian-sks con el que se ejecuta sks.
Le agradecería que alguien pudiera enviar esas ideas a los encargados del paquete. Me tomó MUCHO tiempo darme cuenta de que un directorio inexistente es la razón por la que sks seguía quejándose de que no podía vincular un socket y que probablemente ya lo había hecho otro proceso.
Por si sirve de algo, aquí está el guión rápido que preparé. Parece funcionar bien para mí, pero probablemente podría mejorarse.
#!/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
y aquí está el archivo de servicio systemd para iniciarlo:
[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
Quizás sea una solución fea, pero funciona. Lo probé asegurándome primero de que no había ningún enlace simbólico /var/run o directorio /run/sks, luego ejecuté: systemctl start sks sks-dirmaker sks-recon
el resultado fue que los directorios estaban ahí y SKS se cargó perfectamente.