Php-fpm 7.* - 503 Service Unavailable

Support
1

Problem Description

When running sympl on debian 13 with PHP-FPM 7* the server replies with a 503 Service unavailable. Currently (at time of post) the sympl.io website is also down with the same error.

Any Error Messages

rt php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager.
May 10 20:10:07 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Scheduled restart job, restart counter is at 3.
May 10 20:10:07 hosting.***.co.uk systemd[1]: Starting php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager...
May 10 20:10:07 hosting.***.co.uk php-fpm7.4[2697]: [10-May-2026 20:10:07] ERROR: unable to bind listening socket for address '/etc/sympl/php/7.4/default.sock': Read-only file system (30)
May 10 20:10:07 hosting.***.co.uk php-fpm7.4[2697]: [10-May-2026 20:10:07] ERROR: FPM initialization failed
May 10 20:10:07 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
May 10 20:10:07 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
May 10 20:10:07 hosting.***.co.uk systemd[1]: Failed to start php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager.
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Scheduled restart job, restart counter is at 4.
May 10 20:10:08 hosting.***.co.uk systemd[1]: Starting php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager...
May 10 20:10:08 hosting.***.co.uk php-fpm7.4[2710]: [10-May-2026 20:10:08] ERROR: unable to bind listening socket for address '/etc/sympl/php/7.4/default.sock': Read-only file system (30)
May 10 20:10:08 hosting.***.co.uk php-fpm7.4[2710]: [10-May-2026 20:10:08] ERROR: FPM initialization failed
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
May 10 20:10:08 hosting.***.co.uk systemd[1]: Failed to start php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager.
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Scheduled restart job, restart counter is at 5.
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Start request repeated too quickly.
May 10 20:10:08 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Failed with result 'exit-code'.
May 10 20:10:08 hosting.***.co.uk systemd[1]: Failed to start php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager.
May 10 20:10:30 hosting.***.co.uk systemd[1]: php7.4-fpm.service: Unit cannot be reloaded because it is inactive.

Environment

  • Sympl Version: 13
    sympl-backup 13.20250826.0
    sympl-core 13.20250828.0
    sympl-cron 13.20250826.0
    sympl-dns 13.20250826.0
    sympl-firewall 13.20250826.0
    sympl-ftp 13.20250826.0
    sympl-mail 13.20250828.0
    sympl-monit 13.20250826.0
    sympl-mysql 13.20250826.0
    sympl-phpmyadmin 13.20250826.0
    sympl-updater 13.20250826.0
    sympl-web 13.20251113.0
    sympl-webmail 13.20250826.0

  • Sympl Testing Version:

  • Debian Version: 13

  • Hardware Type: VPS

  • Hosted With: Mythic Beasts

Linux hosting.***.co.uk 6.12.86+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.86-1 (2026-05-08) x86_64
System information as of 2026-05-10 20:01:46 +0000 (UTC)

2

Encountered this too. The only quick fix I could figure was to manually start PHP FPM via the same command used in the service configuration file:

/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf

The service configuration file has been modified recently, so presumably an additional configuration rolled out, which is stopping service from starting successfully.

1 Like
3

I don’t know if it is connected, but this morning doing
sudo apt update && sudo apt -y full-upgrade
got me an error upgrading php 7.4

ExecStart=/usr/sbin/php-fpm7.4 --nodaemonize --fpm-config /etc/php/7.4/fpm/php-fpm.conf (code=exited, status=78)

I’m not sure that php 7.4 is actually being used, but it certainly isn’t working.

4

Thanks Pip for this!
You seem to be correct.
Running this command after reboot is a temporary fix:

sudo /usr/sbin/php-fpm7.4 --fpm-config /etc/php/7.4/fpm/php-fpm.conf
5

That temporary fix seems to work for me.

6

I’m aware of this, and looking at it now, and hope to have it tracked down and have a fix later today.

Note that while the sudo/running PHP will work at the moment, it means that the PHP processes may well have permissions greater than they should, so it’s fairly dangerous.

2 Likes
7

Appreciate it, Paul!

8

Excellent - Thankyou for this and for all your work on the Sympl project as always!

9

Looks like it was a small fix, and that’s on the testing branch now for Bookworm and Trixie.

I’m running it through automated testing and if everything is good I’ll have it pushed out later today.

When I do, it’ll be a quick case of upgrading and running sympl-php-configure manually, but please hold until it’s confirmed working!

3 Likes
10

I was affected by this too. I’ve deleted two WP plugins and manually patched two others on my only hosted site that needed PHP7.4. I thought maybe PHP7.4 would never come back as it’s over 3 years past EOL.

11

Note: this only applies to users who’re running alternate PHP versions in Sympl 12 and 13, those running earlier versions won’t be affected by this.

Anyone affected by this should be able to stop any manually started PHP processes, then:

sudo sympl upgrade

sudo sympl-php-configure

That should fix things up and sites should start working again.

Note that you may want to run sudo apt update ; sudo apt install sympl-web to check for any ‘broken’ packages hanging over from the problem PHP configurations.

For anyone who’s affected but only just noticed, this will get automatically installed overnight and should fix itself when it does.

3 Likes
12

Perhaps you meant:
sudo apt update ; sudo apt install sympl-web

13

Thanks for all the reports – and the fix!

14

Sorry yes, edited to fix!

15

Thank you for the speedy fix.

16

Sorry for the late reply. Was testing and running on development boxes. All working as expected and the nightly update fixed the issues automatically (with your sympl update). Have now deployed to production and all looks good.
Thanks for your help with this.