Php-fpm 7.* - 503 Service Unavailable

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)

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

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.

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

That temporary fix seems to work for me.

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

Appreciate it, Paul!

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

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

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.

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

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

Thanks for all the reports – and the fix!

Sorry yes, edited to fix!

Thank you for the speedy fix.

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.

Thanks for that. Only noticed today and no automatic repair was done. Manually ran the commands and now all good.

Clarification required please?
I’ve just noticed that I’m receiving the following error from a Sympl 12 vm

/etc/cron.hourly/sympl-php-configure:
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Sub-process /usr/bin/dpkg returned an error code (1)
run-parts: /etc/cron.hourly/sympl-php-configure exited with return code 1

I have a couple of sites down which are using older versions of php
Reading the above suggests the following commands will address the issue

sudo apt update ; sudo apt install sympl-web

As always the devil’s in the detail so are the above commands all that’s required or do I need to stop any php processes (there was mention above but it’s not too clear) before running sudo apt update ; sudo apt install sympl-web

Thanks in advance

Yes, as mentioned: run those, it will then fix itself.

You can run an additional sudo sympl-php-configure if you want to be extra sure.

Since running the commands above sites running php-fpm are backonline. For info I have received the output below. Is the below anything to have concerns over?

php8.5 (8.5.6-2) experimental; urgency=medium

  • The systemd unit file has been hardened. Extra options from
    sapi/fpm/php-fpm.service.in has been used:

    ProtectSystem=full
    PrivateDevices=true
    ProtectKernelModules=true
    ProtectKernelTunables=true
    ProtectControlGroups=true
    RestrictRealtime=true
    RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
    RestrictNamespaces=true

    This should work in the default environments, but you might need
    to modify the systemd unit file if you are using less standard
    FPM configuration.

– Ondřej Surý ondrej@debian.org Sun, 10 May 2026 19:35:30 +0200

Regards P