Service 'php-fpm55' down but shouldn't even be on the server

[amphora]

I'm getting this message the last few hours after a server reboot on a Centos 7 server

The service 'php-fpm55' on server xxx is currently down

'Funny' thing is that php 5.5 is not even in my phpX_release settings in custombuild options.conf file.
So why is it even present in DA service monitor?
service php-fpm55 status does return this:

Redirecting to /bin/systemctl status php-fpm55.service
● php-fpm55.service - The PHP FastCGI Process Manager
   Loaded: loaded (/etc/systemd/system/php-fpm55.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2024-01-17 16:45:56 CET; 23s ago
  Process: 7092 ExecStart=/usr/local/php55/sbin/php-fpm55 --nodaemonize --pid=/run/php-fpm55.pid (code=exited, status=203/EXEC)
 Main PID: 7092 (code=exited, status=203/EXEC)

Jan 17 16:45:56 xxx systemd[1]: Starting The PHP FastCGI Process Manager...
Jan 17 16:45:56 xxx systemd[7092]: Failed at step EXEC spawning /usr/local/php55/sbin/php-fpm55: No such file or directory
Jan 17 16:45:56 xxx systemd[1]: php-fpm55.service: main process exited, code=exited, status=203/EXEC
Jan 17 16:45:56 xxx systemd[1]: Failed to start The PHP FastCGI Process Manager.
Jan 17 16:45:56 xxx systemd[1]: Unit php-fpm55.service entered failed state.
Jan 17 16:45:56 xxx systemd[1]: php-fpm55.service failed.

So php 5.5 is apparently still on this server, how to remove it without breaking anything?

 

[Richard G]

Hmmz... odd... where is this coming from then?
Loaded: loaded (/etc/systemd/system/php-fpm55.service; enabled; <--- enabled?

This means it's present and enabled on the server, maybe some old installation still present? Did you have it before or maybe installed manually?
Because if it wouldn't be present, you should see this result on the status request:
Unit php-fpm55.service could not be found.

So php 5.5 is apparently still on this server, how to remove it without breaking anything?

Good question. I don't know how it got on the server before. Normally it's done by removing it from options.conf and then running these commands (which you still can try):

cd /usr/local/directadmin/custombuild
./build update
./build list_removals
./build remove_items

The last command will remove all items listed after the list_removals command.

Another way is to shut it down permanently manually and remove manually.
systemctl stop php-fpm55
systemctl disable php-fpm55 (or php-fpm55.service if that wouldn't work)
After that you can remove the service, remove php-fpm55 directory and also check this file:
/usr/local/directadmin/data/admin/service.status and remove the php-fpm55 line from there too.
restart directadmin afterwards just to be sure.

 

[amphora]

Hmmz... odd... where is this coming from then?
Loaded: loaded (/etc/systemd/system/php-fpm55.service; enabled; <--- enabled?

This means it's present and enabled on the server, maybe some old installation still present? Did you have it before or maybe installed manually?
Because if it wouldn't be present, you should see this result on the status request:
Unit php-fpm55.service could not be found.


Good question. I don't know how it got on the server before. Normally it's done by removing it from options.conf and then running these commands (which you still can try):

cd /usr/local/directadmin/custombuild
./build update
./build list_removals
./build remove_items

The last command will remove all items listed after the list_removals command.

Another way is to shut it down permanently manually and remove manually.
systemctl stop php-fpm55
systemctl disable php-fpm55 (or php-fpm55.service if that wouldn't work)
After that you can remove the service, remove php-fpm55 directory and also check this file:
/usr/local/directadmin/data/admin/service.status and remove the php-fpm55 line from there too.
restart directadmin afterwards just to be sure.

The server used to have php 5.5 but has been replaced ages ago.
./build list_removals doesn't show any php versions.

 

[Richard G]

but has been replaced ages ago.

Probably not the correct way, since it was still enabled, just not running.

So if the list_removals doesn't show any php versions I would suggest to remove manually as in the other instructions given.