Пакет sks, включенный в Ubuntu 20.04 LTS, имеет небольшую, но критическую ошибку. Он настаивает на попытке записать свои файлы сокетов в /var/run/sks. Однако такого каталога нет. Во-первых, /var/run был перемещен в /run, а во-вторых, как tmpfs, /run не обязательно будет иметь каталог sks, если он не был создан ранее.
На данный момент я обошел эту проблему, создав дополнительную службу для sks и sks-recon, которая просто проверяет, существует ли /var/run, если нет, то создает символическую ссылку /run на /var/run, затем проверяет, существует ли /var/run/sks, и если нет, то создает его и меняет его владельца на пользователя debian-sks, от имени которого запускается sks.
Я был бы признателен, если бы кто-то действительно мог переслать такие идеи сопровождающим пакета. Мне потребовалось МНОГО времени, чтобы понять, что несуществующий каталог — это причина, по которой sks постоянно жалуется, что не может привязать сокет и что другой процесс, вероятно, уже сделал это.
Если это имеет значение, вот быстрый скрипт, который я набросал. Кажется, он работает нормально для меня, но, вероятно, его можно улучшить.
#!/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
а вот файл службы systemd для его запуска:
[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
Возможно, это некрасивый способ, но он работает. Я проверил его, сначала убедившись, что нет символической ссылки /var/run или каталога /run/sks, затем я запустил: systemctl start sks sks-dirmaker sks-recon
в результате каталоги были на месте и SKS нормально загрузился.