DirectAdmin Services Not Starting After Reboot? Fix Apache, Exim, MySQL, and CustomBuild Failures

A DirectAdmin server reboot should take 2-3 minutes. When it doesn't come back — or when a CustomBuild update leaves Apache refusing to start, Exim silently dropping mail, and MySQL in a crash loop — you're in a race against angry clients. This guide covers every common post-reboot and post-CustomBuild service failure on DirectAdmin, with the exact commands to diagnose and recover each one.

First: Run the Post-Reboot Diagnostic Checklist

Before touching individual services, run these four checks to understand the full scope of the problem:

# 1. Which services are down?
for svc in directadmin httpd apache2 exim exim4 dovecot mariadb mysql named; do
  systemctl is-active $svc 2>/dev/null | grep -q active && echo "OK: $svc" || echo "DOWN: $svc"
done

# 2. Disk space (full disk = services fail to start)
df -h / /home /var/lib/mysql /var/log

# 3. SELinux enforcing mode (common on AlmaLinux/CentOS post-reboot)
getenforce

# 4. Recent kernel/package updates that may have changed configs
rpm -qa --last 2>/dev/null | head -20    # RPM-based
dpkg --list 2>/dev/null | grep "^ii" | tail -20  # Debian-based

A full disk (/var or / at 100%) explains multiple services failing simultaneously. Clear space before anything else: find /var/log -name "*.gz" -mtime +30 -delete

Fix 1: Apache/httpd Won't Start After CustomBuild Update

The most common cause of Apache failing after a CustomBuild update is a configuration directive that's no longer valid in the new Apache version — typically SuexecUserGroup not allowed in <Directory> context or a PHP handler path that no longer exists.

Check the Apache error output first:

# See the exact syntax error stopping Apache
apachectl configtest
# or
httpd -t 2>&1        # CentOS/AlmaLinux
apache2ctl configtest # Debian/Ubuntu

# Check Apache's own error log
tail -50 /var/log/httpd/error_log
tail -50 /var/log/apache2/error.log

Rebuild Apache configuration via CustomBuild:

cd /usr/local/directadmin/custombuild
./build update
./build rewrite_confs     # Regenerates all Apache/PHP vhost configs
./build apache            # Recompiles Apache (longer, but fixes module mismatches)
systemctl restart httpd 2>/dev/null || systemctl restart apache2

If the error is SuexecUserGroup not allowed in <Directory> context:

# This is caused by mixing Apache 2.4 directives in 2.2-style vhost configs
# CustomBuild's rewrite_confs fixes it — run it first
cd /usr/local/directadmin/custombuild && ./build rewrite_confs

# If still failing, check for custom includes in httpd.conf:
grep -r "SuexecUserGroup" /etc/httpd/conf.d/ /usr/local/apache/conf/extra/ 2>/dev/null

Fix 2: Exim Not Starting (Mail Down After Update)

Exim commonly fails after a CustomBuild update due to a configuration mismatch, a missing library, or a permissions issue on the Exim socket or spool directory.

# Check Exim status and recent errors
systemctl status exim 2>/dev/null || systemctl status exim4
journalctl -u exim -n 50 --no-pager

# Most revealing: run Exim directly to see startup errors
/usr/sbin/exim -bV 2>&1 | head -20

# Check the Exim log
tail -50 /var/log/exim/mainlog 2>/dev/null || tail -50 /var/log/exim4/mainlog

Common error: "socket bind() to port 25 failed: Address already in use" — another process is using port 25:

ss -tlnp | grep :25
# Kill the rogue process if it's not exim:
kill -9 PID
systemctl restart exim

Rebuild Exim via CustomBuild if the binary is mismatched:

cd /usr/local/directadmin/custombuild
./build update
./build exim
./build dovecot
./build rewrite_confs
systemctl restart exim dovecot

Fix Exim spool directory permissions (a common post-migration issue):

chown -R exim:exim /var/spool/exim /var/log/exim 2>/dev/null
chmod 750 /var/spool/exim
systemctl restart exim

Fix 3: MySQL/MariaDB Crash Loop After Reboot

MySQL most often fails after a reboot due to InnoDB crash recovery being unable to complete, a full disk, or a corrupted ibdata1 file from an ungraceful shutdown (e.g., a power failure or force-stop).

# Check MySQL status
systemctl status mariadb 2>/dev/null || systemctl status mysql

# Read MySQL's error log (the most important diagnostic tool)
tail -100 /var/lib/mysql/*.err 2>/dev/null
tail -100 /var/log/mariadb/mariadb.log 2>/dev/null

# If MySQL starts briefly then crashes, watch in real time:
journalctl -u mariadb -f

Force InnoDB recovery mode (for "InnoDB: Database page corruption" errors):

# Add to /etc/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf under [mysqld]:
innodb_force_recovery = 1

systemctl start mariadb

# If it starts — dump all databases immediately:
mysqldump --all-databases > /root/all_databases_recovery.sql

# Then remove the recovery flag, reinstall MySQL, and reimport:
# (Remove innodb_force_recovery line)
systemctl stop mariadb
mv /var/lib/mysql/ib_logfile* /tmp/
systemctl start mariadb
mysql < /root/all_databases_recovery.sql

If disk was full during shutdown, clear space and remove stale lock files:

rm -f /var/lib/mysql/mysql.sock.lock
rm -f /tmp/mysql.sock.lock
systemctl start mariadb

Fix 4: DirectAdmin Daemon Itself Won't Start

If the DirectAdmin admin panel is inaccessible after reboot (port 2222 not responding), the DA daemon itself may have failed:

# Check the DirectAdmin daemon
systemctl status directadmin
/usr/local/directadmin/directadmin d &   # Run in debug mode

# Common cause: license validation failure (no internet on boot)
tail -50 /var/log/directadmin/error.log
tail -50 /usr/local/directadmin/data/users/admin/error.log

# Force license re-check (requires internet access):
/usr/local/directadmin/directadmin o

# If still failing, check the DirectAdmin config:
cat /usr/local/directadmin/conf/directadmin.conf | grep -E "port|ssl|ip"

If DA fails due to a hostname/IP mismatch after a server IP change:

# Update the IP in DirectAdmin config
vi /usr/local/directadmin/conf/directadmin.conf
# Change: ip=OLD_IP → ip=NEW_IP

# Update the license IP via the client area at www.directadmin.com/clients
systemctl restart directadmin

Fix 5: Full CustomBuild Stack Rebuild

When multiple services fail simultaneously after a major OS update or kernel change, a full CustomBuild stack rebuild is often faster than fixing each service individually:

cd /usr/local/directadmin/custombuild

# Update CustomBuild itself first
./build update_custombuild

# Review what has version mismatches
./build versions

# Rebuild the entire stack (takes 20-60 minutes on first run)
./build all d

# After rebuild, restart all services
for svc in httpd exim dovecot mariadb directadmin named; do
  systemctl restart $svc 2>/dev/null
done

The d flag runs in non-interactive mode — it uses defaults for all prompts, which is safe for most production servers. If you have custom options set (e.g., Nginx+Apache, specific PHP versions), verify options.conf before rebuilding: cat /usr/local/directadmin/custombuild/options.conf.

Preventing Service Failures After Reboots and Updates

• Enable service autostart: after any manual fix, verify services are enabled — systemctl enable httpd exim dovecot mariadb directadmin
• Run CustomBuild updates during maintenance windows: never update CustomBuild on a live server during peak hours
• Monitor disk usage: a cron alert at 85% disk usage prevents the full-disk boot failure scenario
• Snapshot before CustomBuild updates: take a VPS snapshot or server backup before running ./build all d
• Test reboots quarterly: scheduled reboots during low-traffic windows catch service autostart issues before an unplanned reboot does

Post-reboot and post-update service failures on DirectAdmin are usually caused by one of five things: a full disk, an SELinux policy block, a CustomBuild config mismatch, a MySQL InnoDB crash, or a license validation race on boot. The diagnostic checklist at the top of this guide identifies which one in under 2 minutes. For managed DirectAdmin server support with proactive monitoring, CloudHouse Technologies' server management service handles updates, reboots, and recovery around the clock.