When a self-compiled PHP-FPM binary is killed by systemd exactly 90 seconds after every start, the cause is almost always a service type mismatch: Ubuntu's php8.3-fpm.service unit declares Type=notify, which requires the binary to send a readiness notification via the systemd notify protocol. A PHP build without systemd integration never sends that message, so systemd concludes the service failed to start, kills it, and reports a timeout. The fix is to build PHP with systemd support enabled — or, less preferably, to change the unit's type.
What the 90-second delay actually means
The number 90 is not arbitrary. It is the default value of TimeoutStartSec in systemd. With a Type=notify unit, systemd considers the service "started" only when the process calls sd_notify() with the string READY=1. Until then, systemd waits — for 90 seconds by default — and if nothing arrives, it logs something like:
php8.3-fpm.service: start operation timed out. Terminating.and sends SIGTERM to the process group. This explains the confusing symptoms that often accompany this problem:
- PHP-FPM does start, listens on its socket, and serves requests correctly during those 90 seconds. Functionality is not the issue; the handshake is.
- The log contains only a terse
Terminating ... exiting, bye-bye!, because that is the PHP-FPM master process reacting to the termination signal, not reporting an internal error. - Running
systemctl start php8.3-fpmappears to hang for the same 90 seconds — the command blocks until systemd gives up on the readiness notification. - The PID file exists and is current. PID files prove nothing here; with
Type=notify, systemd does not use them to decide whether startup succeeded.
Why source builds break the handshake
Distribution-packaged PHP binaries are built with systemd notification support compiled in. When you download the PHP source tarball and configure it yourself, that integration is disabled by default. The resulting binary is a perfectly valid FPM server — it just never talks to systemd, so a unit expecting notification will always time out.
The general rule: any time you replace a packaged daemon with a hand-built binary, the service unit that ships with the package may no longer match the binary's behavior. Service type, socket paths, user settings, and configuration file locations all become candidates for drift.
The proper fix: compile PHP with systemd support
Reconfigure and rebuild PHP so the FPM binary includes the systemd integration:
./configure \
--enable-fpm \
--with-fpm-systemd \
...your other options...
make && make installWith --with-fpm-systemd, the FPM master process calls the notify API once it is listening and ready, satisfying the Type=notify contract. After installing, run systemctl daemon-reload (in case unit files changed) and start the service normally. Startup should return immediately and the process should survive indefinitely.
On some setups you may also need to ensure the pkg-config files for systemd are available at build time, since the configure script checks for them; if --with-fpm-systemd silently has no effect, install the systemd development package and re-run configure.
The quick workaround: change the unit type
If rebuilding is not immediately practical, edit /usr/lib/systemd/system/php8.3-fpm.service and replace Type=notify with Type=simple. Under Type=simple, systemd considers the process started as soon as it forks, with no notification handshake required. Reload the unit afterward:
systemctl daemon-reload
systemctl restart php8.3-fpmThis works, but it is a workaround, not a repair. You lose systemd's ability to track true readiness and to accurately report service state, and the edited unit file will be overwritten the next time the packaged PHP is upgraded. Prefer the rebuild when you can.
Think carefully before building PHP from source
Getting the version number you want is often the motivation for a source build, but on Ubuntu the packaged version number understates what you actually get. The distribution backports security fixes into its packaged releases while keeping the original upstream version string, so an apt-installed PHP can contain patches that upstream released much later.
Switching to a self-built PHP also transfers the entire maintenance burden — security monitoring, rebuilding on every advisory, rebuilding dependent extensions, and regression testing — from the distribution to you. That work repeats for every update, forever. Unless you need a configuration or feature the packages cannot provide, staying on the packaged build is usually the lower-risk choice.
Frequently Asked Questions
Why does the site still work during those 90 seconds?
PHP-FPM starts and listens immediately; the timeout is about systemd's readiness check, not the daemon's ability to serve. When systemd's 90-second timer expires, it terminates the processes, and the site goes down at that point.
Where can I see the timeout message?
Run journalctl -xeu php8.3-fpm.service. A "start operation timed out. Terminating." entry is the signature of this problem, and the elapsed time will match your TimeoutStartSec value.
Does the PID file being present change anything?
No. With Type=notify, systemd ignores PID files as a readiness indicator. It only accepts the READY=1 notification from the process itself.
How do I check whether my FPM binary has systemd support?
Run php-fpm -i | grep -i systemd or inspect the configure options embedded in the build. If the binary was not configured with --with-fpm-systemd, it will not send readiness notifications.
Can I just increase TimeoutStartSec instead?
That only delays the inevitable. Without the notification, no timeout is long enough — the service will still be killed eventually. Fix the handshake or change the unit type.
Will changing the unit file break future updates?
Yes, potentially. Files under /usr/lib/systemd/system are package-owned and get replaced on upgrades. If you must edit, copy the unit to /etc/systemd/system and modify it there so your change takes precedence and survives package updates.