CustomBuild 2 is the backbone of every DirectAdmin server — it compiles Apache, PHP, MySQL/MariaDB, Exim, and a dozen other services from source. When a build fails mid-upgrade or mid-install, you're left with a server that's half-updated and potentially broken. Sites may 500. PHP may stop serving. MySQL might refuse to start.
This guide covers the most common CustomBuild 2 failure scenarios — with the exact commands to diagnose each error and get your build completing cleanly.
Where CustomBuild Logs Live
Before running any build commands, know where to find the output. CustomBuild writes detailed logs to /usr/local/directadmin/custombuild/.
# Always tail the most recent build log first
ls -t /usr/local/directadmin/custombuild/*.log | head -5
# Watch a build in progress
tail -f /usr/local/directadmin/custombuild/build.log
The log will show the exact make or configure error that caused the failure. Never try to fix a build error without reading this log — guessing wastes time and risks making the server state worse.
Step 1: Update CustomBuild Before Anything Else
An outdated CustomBuild script itself causes many build failures. Always update first:
cd /usr/local/directadmin/custombuild
./build update
This fetches the latest build scripts and package versions from DirectAdmin's servers. If the build update command itself fails with a certificate or SSL error:
./build update_now
Or manually pull the latest script:
wget -O /usr/local/directadmin/custombuild/build https://files.directadmin.com/services/custombuild/2.0/build
chmod 755 /usr/local/directadmin/custombuild/build
Fix 1: Missing System Dependencies (Most Common)
CustomBuild compiles from source, which means it needs C compilers, development headers, and system libraries. If these are missing or outdated, the configure step fails immediately.
Error message example:
configure: error: C compiler cannot create executables
configure: error: libtool not found
configure: error: libxml2 not found
Fix for CentOS/AlmaLinux/CloudLinux:
yum groupinstall -y "Development Tools"
yum install -y gcc gcc-c++ make autoconf automake libtool libxml2-devel openssl-devel zlib-devel bzip2-devel curl-devel libpng-devel libjpeg-devel freetype-devel libmcrypt-devel mariadb-devel cmake perl
Fix for Debian/Ubuntu:
apt-get install -y build-essential gcc g++ make autoconf automake libtool libxml2-dev libssl-dev zlib1g-dev libbz2-dev libcurl4-openssl-dev libpng-dev libjpeg-dev libfreetype6-dev libmysqlclient-dev cmake perl
After installing dependencies, retry the build:
./build clean
./build all d
Fix 2: Apache Build Fails
Error: "libtool not found" or APR Build Failure
buildconf: libtool not found. You need libtool version 1.4 or newer installed to build APR
CustomBuild bundles its own libtool. Build it first:
./build libtool
./build apache
Error: Apache 2.4 Version Conflict
CustomBuild 2.0 does support Apache 2.4 only. Please check your apache_ver value in options.conf
Open /usr/local/directadmin/custombuild/options.conf and verify:
grep "apache_ver" /usr/local/directadmin/custombuild/options.conf
It should read apache_ver=2.4. If it shows 2.2 or another value, update it:
sed -i 's/^apache_ver=.*/apache_ver=2.4/' /usr/local/directadmin/custombuild/options.conf
./build apache
Apache Fails to Start After Build
If the build completes but Apache won't start:
apachectl configtest
journalctl -u httpd -n 50 --no-pager
Syntax errors in VirtualHost configs (often caused by a partially upgraded PHP config) are the most common post-build Apache start failure. Use apachectl configtest — it shows the exact file and line causing the issue.
Fix 3: PHP Build Fails
Error: Cannot Find MySQL/MariaDB Headers
configure: error: Cannot find MySQL header files
configure: error: Please reinstall the libmysqlclient-dev package
PHP needs MariaDB development headers to compile with MySQL support. Install them:
# CentOS/RHEL
yum install -y mariadb-devel
# Debian/Ubuntu
apt-get install -y libmariadb-dev libmariadb-dev-compat
If you've recently upgraded MariaDB via CustomBuild and then PHP fails:
./build mariadb
./build php n
The order matters — rebuild MariaDB first so its headers are current before PHP tries to compile against them.
Error: PHP Build Succeeds but Sites Show Blank Pages or PHP Errors
The php.ini files may not have been regenerated after the build. Force a rebuild of PHP configuration:
./build php_ini
Then restart PHP-FPM:
systemctl restart php-fpm
# or for PHP-FPM with specific version:
systemctl restart php8.2-fpm
Building Multiple PHP Versions
DirectAdmin supports multiple concurrent PHP versions. To build a specific version:
# List available PHP version options
./build set php1_release 8.1
./build set php2_release 8.2
# Build all configured PHP versions
./build php
After building, assign PHP versions per domain in DirectAdmin under Account Manager → Domain Setup.
Fix 4: MySQL/MariaDB Build or Start Failure
Error: MySQL Socket Not Found After Build
Can't connect to local MySQL server through socket '/tmp/mysql.sock'
This happens when MySQL starts but the socket file ends up in a different location than PHP expects. Check where MySQL is actually putting its socket:
grep "socket" /etc/mysql/my.cnf /etc/my.cnf 2>/dev/null
mysqladmin status 2>&1 | grep socket
If the socket path in my.cnf doesn't match what PHP is compiled to use (/tmp/mysql.sock vs /var/run/mysqld/mysqld.sock), rebuild PHP ini to pick up the correct path:
./build php_ini
MariaDB Fails to Start After CustomBuild Upgrade
journalctl -u mariadb -n 100 --no-pager
Common causes:
- InnoDB log file size mismatch: The new version expects different log file sizes. Delete the old ib_logfile* files (after stopping MariaDB) and let the new version create fresh ones.
- Data directory permission issue:
chown -R mysql:mysql /var/lib/mysql - Incompatible table format: Run
mysql_upgradeafter starting MariaDB to update system tables to the new version's format.
systemctl stop mariadb
rm -f /var/lib/mysql/ib_logfile*
systemctl start mariadb
mysql_upgrade -u root -p
Fix 5: Full Rebuild After Catastrophic Failure
If multiple components are broken and you're not sure what to rebuild first:
# Clean all compiled files (does not remove data)
./build clean
# Rebuild in dependency order
./build libtool
./build zlib
./build openssl
./build apache
./build mariadb
./build php
./build exim
./build dovecot
# Restart all services
./build restart_services
The ./build all d command handles this sequence automatically, but running individual components gives you more visibility if one fails.
Verifying the Build Was Successful
# Check Apache version
httpd -v || apache2 -v
# Check PHP version (all installed)
/usr/local/php82/bin/php -v
/usr/local/php81/bin/php -v
# Check MariaDB version
mysql --version
# Check all DirectAdmin services
/usr/local/directadmin/directadmin status
service_list="httpd mariadb exim dovecot named"
for svc in $service_list; do systemctl status $svc --no-pager | head -3; done
Preventing Future Build Failures
- Always snapshot or backup before running a major CustomBuild upgrade —
./build allrewrites multiple services simultaneously. - Run builds during low-traffic hours — compilation takes 20-60 minutes and services restart during the process.
- Keep the OS base packages updated:
yum update -yorapt-get upgrade -y— stale system libraries cause build failures more often than CustomBuild bugs. - Don't mix manual PHP installs with CustomBuild — if you manually installed a PHP version from an OS repo, it may conflict with CustomBuild's compiled version. Use CustomBuild exclusively for all software it manages.
If your DirectAdmin server's CustomBuild environment has compounding failures that this guide doesn't resolve, CloudHouse Technologies' server management team specialises in DirectAdmin infrastructure — including CustomBuild recovery, PHP stack upgrades, and post-migration server rebuilds.
