# DirectAdmin Service Monitor false restarts and systemd status handling

Source: https://srvscripts.com/guides/directadmin-service-monitor-false-restarts/
Updated: 2026-10-06
Publisher: srvScripts (https://srvscripts.com/)

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.

In short: 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.

**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](/guides/directadmin-da-cli/) cover the config keys referenced above.

## DirectAdmin Service Monitor false restarts at a glance

**Official documentation:** [DirectAdmin documentation](https://docs.directadmin.com/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [DirectAdmin license errors and update failures: da update, IP/hostname mismatches](https://srvscripts.com/guides/directadmin-license-error-update-failures/) · [KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback](https://srvscripts.com/guides/kernelcare-setup-cpanel-directadmin/) · [Running Node.js and Python apps with Nginx Unit and per-user Redis on DirectAdmin](https://srvscripts.com/guides/directadmin-nginx-unit-apps-redis/).

## Frequently asked questions

### Does the DirectAdmin Service Monitor also watch php-fpm and named?

Yes. Any unit listed as `ON` in `services.status` is checked, which by default includes the per-version `php-fpm` units, `named`, the FTP server and the mail stack; a service without a systemd unit cannot be monitored on 1.691 and later.

### How long does the Service Monitor wait before restarting a service?

It checks every minute through `dataskq` and restarts on the first check that finds the unit not `active`, with no grace period, which is why a start or reload taking longer than the check interval produces a false restart.

### Can I undo this?

Yes. Remove the systemd drop-in with `systemctl revert <unit>` followed by `daemon-reload`, and restore the previous `services.status` entries; disabling a service’s entry on the Service Monitor page is also reversible at any time.