DirectAdmin Service Monitor false restarts and systemd status handling

DirectAdmin’s Service Monitor keeps the core daemons running: if Exim, Dovecot, MariaDB, the web server or the panel’s helpers are found stopped, it starts them and emails the admin. In 1.691 the monitor was rewritten to rely on systemd alone rather than on process names and PID files, which removed a whole class of mistakes but introduced a different one. Services that are running but whose unit reports something other than active now get restarted, and a service the monitor cannot map to a unit is reported as down forever. This guide explains the logic and the fixes.

Short answer: Since 1.691 the Service Monitor asks systemd for each unit in services.status and treats anything other than active as down, so slow-starting services stuck in activating, graceful reloads caught in reloading, and stale unit names all trigger restarts. Fix the unit with a drop-in that sets a realistic TimeoutStartSec or readiness notification, keep services.status in step with the installed stack, and leave notifications on.

How the monitor decides

Every minute the dataskq task runner reads the list of monitored services from /usr/local/directadmin/data/admin/services.status, and for each one marked ON asks systemd for the unit’s state:

cat /usr/local/directadmin/data/admin/services.status
systemctl is-active exim dovecot mariadb httpd directadmin

Only active counts as up. activating, deactivating, reloading and failed all count as down and trigger a restart. That is correct for failed, but a service that spends a long time in activating on every start, or that is reloading when the check lands, gets restarted mid-operation, and the admin receives a notification that reads like a crash.

The unit names the monitor expects are the standard ones for the distribution: httpd on AlmaLinux and apache2 on Debian and Ubuntu, mariadb or mysqld depending on the CustomBuild database choice, php-fpm84 per PHP version, named, pure-ftpd or proftpd, and exim, dovecot, spamassassin or rspamd. The monitor has no way to watch a service that has no unit, which is the change from older versions that could match a process by name.

Case one: a slow-starting service

MariaDB with a large InnoDB buffer pool, or a web server with thousands of virtual hosts, can sit in activating for a minute or more. If the monitor checks during that window it issues a second start, systemd rejects it or queues it, and the log fills with restart notices while the service is in fact fine.

The cure is on the unit side. Give the unit a realistic start timeout and, for services that support it, Type=notify so systemd learns when the service is actually ready. Do not edit the vendor unit; add a drop-in:

systemctl edit mariadb

[Service]
TimeoutStartSec=300

Then systemctl daemon-reload. The monitor still sees activating during those minutes, so on servers where this happens often, disable monitoring for that service in Admin Level → Service Monitor while it is starting or accept the single notification.

Case two: reload treated as down

da build rewrite_confs and the ACME renewal task both reload the web server. Apache’s graceful reload can leave the unit in reloading for a few seconds on busy servers, and a monitor check in that window restarts Apache, dropping the connections the graceful reload was preserving. If restart notices coincide with configuration rewrites in /var/log/directadmin/system.log, this is the cause.

Check the timing in the two logs:

grep -i 'service monitor\|restart' /var/log/directadmin/system.log | tail -20
journalctl -u httpd --since '1 hour ago' | grep -iE 'reload|start'

Most of these cases disappear once Apache runs with mod_systemd and reports readiness, which the CustomBuild Apache 2.4.68 build does on AlmaLinux 9 and 10. On builds that lack it, lengthen the interval between the monitor’s checks if your build exposes it, or move rewrites to a quiet period.

Case three: the wrong unit name

After switching MariaDB to MySQL, or nginx to LiteSpeed, the services.status file may still list the old unit. The monitor marks it down every minute and, because the unit does not exist, never succeeds in starting it. The notification email repeats until the entry is corrected. There is no CustomBuild target that rewrites this file (da build set_service_status does not exist on DirectAdmin 1.712), so compare the file with the units that are really running:

grep -v '^#' /usr/local/directadmin/data/admin/services.status
systemctl list-units --type=service --state=running | grep -E 'exim|dovecot|maria|mysql|httpd|nginx|lsws'

Each line is unit=ON, for example mysqld=ON or php-fpm83=ON. Change or remove the line for the unit that no longer exists (the file is owned by diradmin, mode 600), then run systemctl restart directadmin.

Common pitfall: masking notifications instead of fixing state

Turning off the email notification in Administrator Settings silences the symptom while the monitor keeps restarting the service. Fix the unit state first; keep the notification on afterwards, because a monitor that restarts Exim every minute costs deliveries and a monitor that restarts MariaDB costs uptime.

Verify

Watch the monitor for a full cycle after the change. The system log should show no restart entries for the affected service, and the unit should remain active through a configuration rewrite:

da build rewrite_confs
sleep 90
systemctl is-active httpd
grep -c 'Service Monitor' /var/log/directadmin/system.log

Also confirm the notification address in Administrator Settings is one that is actually read, so the next genuine crash is noticed. For a broader view of what is running and consuming resources, the per-user resource graphs added in 1.703 complement the service-level monitor, and the checks in The da CLI guide cover the config keys referenced above.

DirectAdmin Service Monitor false restarts at a glance

Official documentation: DirectAdmin documentation, Linux man pages.

Related guides: DirectAdmin license errors and update failures: da update, IP/hostname mismatches · KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback · Running Node.js and Python apps with Nginx Unit and per-user Redis on DirectAdmin.

Frequently asked questions