DirectAdmin CustomBuild 2 Failed? Fix Apache, PHP, and MySQL Build Errors

Priya

Content Writer & Researcher

Last Updated: 25 July 2026
DirectAdmin CustomBuild 2 Failed? Fix Apache, PHP, and MySQL Build Errors
🖥️

DirectAdmin CustomBuild Failing on Your Server?

Our DirectAdmin server management team handles CustomBuild failures, PHP stack upgrades, and post-migration server rebuilds — restoring full functionality fast.

🖥️12,400+PCs Fixed
⭐4.9★Google Rating
⚡<15 minAvg. Response
🛡️ISO 27001Certified

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_upgrade after 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 all rewrites 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 -y or apt-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.

Get the Free Linux Server Admin Cheatsheet (PDF)

Essential commands for server management, networking, and troubleshooting — all on one printable page.

Running Linux servers? Let us manage them for you.

Our Managed Linux Server plans cover updates, security hardening, monitoring, and 24/7 incident response — so your servers stay up and your team stays focused.

  • Proactive OS patching and security updates
  • 24×7 monitoring with instant alerting
  • Backup configuration and disaster recovery
  • Dedicated Linux engineers on call
See Pricing Plans →

What our customers say

“Our production server went down at 2 AM. CloudHouse had it back online in under 20 minutes. Incredible response time.”

Arun S.

CTO, SaaS Startup

“They migrated our entire infrastructure from Ubuntu 18 to 22 with zero downtime. Couldn't have asked for better.”

Deepak N.

DevOps Lead

Frequently Asked Questions

A full ./build all run on a typical VPS (2-4 vCPU, 4-8 GB RAM) takes 20-45 minutes. Compilation time scales with CPU speed — on a powerful dedicated server it can complete in under 15 minutes. On older or low-resource VPS instances it may take over an hour. Plan the build during low-traffic windows since Apache and PHP-FPM restart during the process.

Need this done for you?

Server Management Service

Managed Linux and Windows servers: monitoring, patching, security and 24/7 support.

Learn more

Book your free 15-minute diagnosis

A certified technician will call you back within 15 minutes during business hours.

Share this article

Leave a Comment

Comments (0)

Loading comments...