Failed to restart php8.3-fpm.service: Unit php8.3-fpm.service not found

The unit name does not match what is installed. Run systemctl list-unit-files 'php*fpm*' to see the real name, then restart that one. Most often you typed a PHP version the server does not have.

$ sudo systemctl restart php8.5-fpm
Failed to restart php8.5-fpm.service: Unit php8.5-fpm.service not found.

$ systemctl list-unit-files 'php*fpm*'
UNIT FILE           STATE
php8.3-fpm.service  enabled

$ sudo systemctl restart php8.3-fpm

This is a different failure from Job for php-fpm.service failed. That one means FPM exists and rejected its configuration. This one means systemd has no unit by that name at all, so nothing was even attempted.

The causes, in order of how often they appear

1. The version in the command is not the version installed. On Debian and Ubuntu the unit is versioned: php8.3-fpm, never just php-fpm. A command copied from a guide written for another release names a version you do not have. This happens constantly with PHP 8.5, which most distribution repositories and many control panels do not ship yet. Check what you actually run with php -v and ls /etc/php/.
2. PHP is installed but FPM is not. php8.3-cli and libapache2-mod-php8.3 are separate packages from php8.3-fpm, so php -v working proves nothing about FPM. Install it explicitly:

   sudo apt install php8.3-fpm
   systemctl list-unit-files 'php*fpm*'

3. You are on a RHEL family system. RHEL, Rocky and Alma name the unit php-fpm.service with no version. If you installed PHP from the Remi repository the name is different again, for example php83-php-fpm.service. Use the list command above rather than guessing.
4. The package is half configured. An interrupted upgrade can leave the package installed but its unit never registered. dpkg -l | grep php8.3-fpm showing iF or iU instead of ii confirms it. Finish the configuration with sudo dpkg --configure -a.
5. You wrote a unit file by hand and systemd has not seen it. A new file under /etc/systemd/system/ is invisible until systemd reloads its configuration: sudo systemctl daemon-reload.

If you upgraded PHP versions

Installing a new PHP release does not remove the old one, and both FPM units can exist side by side. After an upgrade, check three places still name the old version: your restart scripts and deploy hooks, the nginx fastcgi_pass socket path, and any cron jobs. A deploy script still restarting php8.1-fpm after you moved to 8.3 produces exactly this error, or worse, silently restarts the old version while the site runs on the new one.

# every FPM unit on the box, running or not
systemctl list-units 'php*-fpm*' --all

# which socket nginx is actually pointed at
grep -r fastcgi_pass /etc/nginx/

How to stop it happening again

Never hard-code the version in scripts. Resolve the unit name at run time instead:

UNIT=$(systemctl list-unit-files 'php*fpm*' --no-legend | awk '{print $1}' | head -1)
sudo php-fpm8.3 -t && sudo systemctl reload "$UNIT"

That keeps deploy scripts working across PHP upgrades, and the config test in front of the reload means a broken pool never reaches the running daemon.

Related

• Job for php-fpm.service failed: when the unit exists but FPM rejects its configuration.
• Job for nginx.service failed: the web server half of the same stack, plus the full systemd exit-code table.
• systemd service unit generator: write a correct unit file instead of copying one.