Что должен уметь демон, чтобы его можно было перезапустить/стартовать из systemd?

в случае с type=simple и другими вариациями - ничего отличного от обычной работы програмки.
с type=dbus демону потребуется уметь работать с d-bus.

https://www.freedesktop.org/software/systemd/man/daemon.html

Раздел New-Style Daemons. В самом простом случае достаточно обрабатывать SIGTERM (опционально SIGHUP) и давать корректные коды возврата.

Ок, спасибо тебе, добрый человек!

D-bus точно не пригодится. И, да, скорее всего именно type=simple

Спасибо!

А что должно быть в самом демоне, чтобы обеспечить поддержку start/restart/stop средствами systemd?

По большому счёту, ничего. Для systemd даже «делать демона» не нужно — ты можешь обойтись просто процессом, который вечно работает на переднем плане и корректно реагирует на SIGTERM (или любой другой сигнал по твоему выбору, но тогда его нужно будет прописать в юните как KillSignal=).

Единственное (на правах совета) — чтобы systemd правильно понимал, когда твой демон закончил загружаться и начал работать, есть смысл сделать Type=notify, слинковаться с libsystemd и вызвать sd_notify("READY=1") по окончании загрузки. Это нужно по большому счёту для удобства администратора: systemctl start будет ждать окончания загрузки демона перед тем, как возвращать управление, и показывать проблемы в случае их возникновения. Если так не сделать, systemctl будет возвращать управление моментально, даже если демон, условно, упадёт через 500 мс из-за ошибки чтения конфига.

Учту, спасибо!

К великому счастью, ничего. Ни двойного форка, ни отвязки от терминала, ни процессных групп, ни сессий, ни пидфайлов (а без рейсов? а если pid другому процессу выделен?), ни самодельного логгирования, ни переоткрывания логов по USR1 для ротации, ни открытия fd 0/1/2 из/в /dev/null, ни сброса прав. Поэтому systemd (или так и быть, полноценные супервайзеры в целом) и рулит по сравнению со всякими недоrc.

Т.е., как написал intelfx?

А logrotate настраивается отдельно?

Если ты пишешь в stdout/stderr, то оно попадает в journald и там всё само работает как надо.

Если ты пишешь в stdout/stderr, то оно попадает в journald и там всё само работает как надо.

Помнится были там проблемы с буфферизацией, особенно если Python-скрипты в unit’ы заворачивать, х.з. как сейчас.

Вот с логами есть вопрос: их хотят забирать по sftp. journald позволит складывать файлы в произвольное место? Или достаточно будет сделать симлинк на нужную директорию?

Нельзя. С подобными требованиями лучше логи писать самостоятельно и настроить logrotate.

Ок, спасибо!

Type=notify, слинковаться с libsystemd и вызвать sd_notify(«READY=1»)

совет корректный и полезный, но меня ужаснула одна мысль о том, чтобы линковаться с чем-то подобным, в эрланге это больно, так что родилось такое:

https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb

Там внутри просто открыть UDP сокет по пути из окружения и написать туда что-то.

я бы сказал, что в 2022-м году вообще очень неправильно тратить своё время на писание логов куда-то кроме stdout. И в чём либо кроме жсон формата.

прописываешь в юните в какое место писать stdout, stderr и океюшки.

Ну естественно, там «протокол» намеренно простой как полкопейки.

я почитал, там оказывается есть всякие расширения в хедерах сообщения, но в целом это не требуется.

хартбит неплохая штука, но всё это в теории можно и не делать, просто выкинуть на помойку истории все функции типа daemonize и т.п. и жить с stdin/stdout