У меня проблема с несколькими серверами (это происходило дважды, по одному в месяц), когда запуск Daily apt upgrade and clean activities по какой-то причине останавливает мою конкретную службу, а затем никогда не запускает ее, поэтому она отключена, и мне нужно запустить ее вручную.
В системных журналах я вижу это:
Mar 7 06:59:24 server systemd[1]: Starting Daily apt upgrade and clean activities...
Mar 7 06:59:38 server systemd[1]: Reloading.
Mar 7 06:59:38 server systemd[1]: Started ACPI event daemon.
Mar 7 06:59:38 server systemd[1]: Stopping Odoo 11...
Mar 7 06:59:39 server systemd[1]: Stopped Odoo 11.
Mar 7 06:59:39 server systemd[1]: Stopped PostgreSQL RDBMS.
Mar 7 06:59:39 server systemd[1]: Stopping PostgreSQL Cluster 9.5-main...
Mar 7 06:59:41 server systemd[1]: Stopped PostgreSQL Cluster 9.5-main.
Mar 7 06:59:42 server systemd[1]: Reloading.
Mar 7 06:59:42 server systemd[1]: Starting Daily apt download activities...
Mar 7 06:59:42 server systemd[1]: Started ACPI event daemon.
Mar 7 06:59:42 server systemd[1]: Reloading.
Mar 7 06:59:42 server systemd[1]: Started ACPI event daemon.
Mar 7 06:59:42 server systemd[1]: Starting PostgreSQL Cluster 9.5-main...
Mar 7 06:59:45 server systemd[1]: Started PostgreSQL Cluster 9.5-main.
Mar 7 06:59:45 server systemd[1]: Starting PostgreSQL RDBMS...
Mar 7 06:59:45 server systemd[1]: Started PostgreSQL RDBMS.
Mar 7 06:59:51 server systemd[1]: Started Daily apt upgrade and clean activities.
Mar 7 06:59:59 server systemd[1]: Started Daily apt download activities.
Как видно из журнала, когда он запускается, он также запускает демон событий ACPI, который затем останавливает службу Odoo 11 , но эта служба остается остановленной, даже если это не должно быть.
А вот конфиг systemd для сервиса Odoo 11:
[Unit]
Description=Odoo 11
Requires=postgresql.service
After=postgresql.service
[Service]
Type=simple
PermissionsStartOnly=true
User=odoo
Group=odoo
SyslogIdentifier=odoo11
ExecStart=/opt/odoo/venv/bin/python3 /opt/odoo/odoo/odoo-bin -c /etc/odoo11.conf
[Install]
WantedBy=multi-user.target
Может быть, что-то не так с конфигурацией службы systemd start-stop? Хотя, если я запускаю этот сервис сам, он работает как задумано.