переход с supervisor на systemd

 Автоматический перезапуск решается штатно, через Restart=always или более правильное Restart=on-failure. Помним про дополнительные StartLimit* итд для постоянного рестарта при нескольких неудачах.

Вопрос сложнее - чем заменить numprocs из supervisor. Мне удалось найти только 1 вариант, через имя с @

https://unix.stackexchange.com/questions/288236/have-systemd-spawn-n-processes

Ну и логи иногда нужны в файлах, тогда есть

StandardOutput=/path_to_log/service.log

StandardError=/path_to_log/service_error.log

Может быть =syslog, тогда будет пойдёт через подсистему рсислога (+ SyslogIdentifier=)

Ну и помним про "костыль" вида ExecStart=aaa >/var/log/1 2>&1

переход с crontab на systemd timer

 Если вкратце:

1) делаем сервис с Type=OneShot

2) делаем таймер, который запускает этот сервис

Более подробно и примеры

https://opensource.com/article/20/7/systemd-timers

Строка запуска раз в минуту будет такой:

OnCalendar=*-*-* *:*:00

PS команда для быстрого создания сервиса без возни с файлами:

systemctl edit --full --force cron.service

systemctl edit --full --force cron.timer

Методы обновления сертификатов lets encrypt (certbot)

 Классика:

certbot renew

но есть и готовый сервис

systemctl status certbot.timer

...

   Triggers: ● certbot.service

systemctl status certbot

○ certbot.service - Certbot

     Loaded: loaded (/lib/systemd/system/certbot.service; static)

     Active: inactive (dead) since Tue 2023-05-02 13:11:37 MSK; 1s ago

TriggeredBy: ● certbot.timer

Сервис, запускаемый по таймеру и обновляющий сертификаты.

Но нужно проверять: бывает что certbot renew работает, а сервис завершается с ошибкой.

PS можно доработать сервис (edit --full) и добавить в Exec в конец

--post-hook "nginx -t && systemctl reload nginx"

тогда не надо ничего придумывать с перезапуском nginx. При необходимости заменить на нужный сервис.

systemd restart=always

 так, памятка чтобы системд вечно рестартил сервис

Необходимо, но не достаточно restart=always :

The default limit is to allow 5 restarts in a 10sec period. If a service goes over that threshold due to the Restart= config option in the service definition, it will not attempt to restart any further.

The rates are configured with the StartLimitIntervalSec= and StartLimitBurst= options and the Restart= option controls when SystemD tries to restart a service.

fail2ban+systemd+sshd

У fail2ban начиная с версии 1.9.0 есть поддержка опции

backend = systemd

Но в centos, debian (например в 8) чаще 0.8, поэтому тут решение - подключать rsyslog

apt-get install rsyslog

/etc/rsyslog.d/sshd.conf:

authpriv.*      /var/log/auth.log

systemctl enable rsyslog

systemctl start rsyslog

ls -la /var/log/auth.log

И теперь как обычно

cat >> /etc/fail2ban/jail.local << EOF
[ssh]

enabled = true

bantime = 12m

EOF

(в случае centos поправить имя блока до sshd, файл лога при этом писать не в auth.log а в /var/log/secure, но в центос обычно rsyslog уже из коробки настроен как надо)

systemd: rsyslog больше не пишет логи

Очень подробно проблема описана тут
http://unix.stackexchange.com/questions/124942/rsyslog-not-logging

Также может быть связано с /var/log/journal, повреждением записей или удалением этого каталога. Права выглядят примерно так
drwxr-sr-x  3 root     systemd-journal
Вроде можно просто создать /var/log/journal и при перезапуске сервера/journal сервисов права выставит как надо.
Также иногда нужно закомментировать $OmitLocalLogging on в rsyslog.conf

И быстрый фикс:
rm -f /var/lib/rsyslog/imjournal.state
service rsyslog restart

systemd: больше информации по service файлам

По опциям для .service файлов даже гугл выдаёт совсем не то, что просят. В частности, почти нереально сделать запрос так, чтобы найти аналог того же locked memory (-l), но без ulimit.
И вот она, табличка:

Table 1. Resource limit directives, their equivalent ulimit shell commands and the unit used

Directive	ulimit equivalent	Unit
LimitCPU=	ulimit -t	Seconds
LimitFSIZE=	ulimit -f	Bytes
LimitDATA=	ulimit -d	Bytes
LimitSTACK=	ulimit -s	Bytes
LimitCORE=	ulimit -c	Bytes
LimitRSS=	ulimit -m	Bytes
LimitNOFILE=	ulimit -n	Number of File Descriptors
LimitAS=	ulimit -v	Bytes
LimitNPROC=	ulimit -u	Number of Processes
LimitMEMLOCK=	ulimit -l	Bytes
LimitLOCKS=	ulimit -x	Number of Locks
LimitSIGPENDING=	ulimit -i	Number of Queued Signals
LimitMSGQUEUE=	ulimit -q	Bytes
LimitNICE=	ulimit -e	Nice Level
LimitRTPRIO=	ulimit -r	Realtime Priority
LimitRTTIME=	No equivalent	Microseconds

отсюда: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Выбираем, ставим. Размерности тоже принимаются. Для бесконечности ставим infinity
Также в помощь man systemd.directives

CentOS 7: включаем core dump

Обычно достаточно модифицировать service файл, добавив
[Service]

LimitCORE=infinity

или глобально, в /etc/systemd/system.conf

DefaultLimitCORE=infinity

Иногда требуется выставить

kernel.core_uses_pid = 1

fs.suid_dumpable = 2

Обычно этого достаточно.

CentOS 7 и сокет-файлы

Суть в том, что раньше многие писали сокет файлы в /tmp, а сейчас например при запуске сервиса uwsgi + nginx с сокетом в /tmp при попытке обратиться можно поймать
(2: No such file or directory) while connecting to upstream
и долго ломать голову, что же не так.

Это systemd security feature, корни примерно тут
[Service]
PrivateTmp=true
И если подумать, это правильно. Учимся использовать /run (в центос 7 оно же /var/run в виде симлинка на ../run)

Не путаем с permission denied, что обычно из-за прав на сокет файл или каталог где он лежит. ИЛИ - из-за selinux, проверить getenforce, который входит в пакет libselinux-utils. Если Enforced - переводим в permissive и проверяем снова
setenforce permissive

Не забываем потом перенастроить selinux или отключить его.
http://stackoverflow.com/questions/26334526/nginx-cant-access-a-uwsgi-unix-socket-on-centos-7