The other day, my hosting provider initiated a forced reboot of the server I use to run this website. Unfortunately, this resulted in some unanticipated down time. Now I should note, I’m a web application developer, not a system administrator. I really run this server has a hobby an as an opportunity to learn. But in my professional career, I delegate the responsibilities of setting up these things to a team of talented system administrators. With the site down, I was seeing entries like this in my logs:
2019/10/26 23:25:45 [error] 1178#1178: *620 connect() failed (111: Connection refused) while connecting to upstream, client: 126.96.36.199, server: www.john-brandenburg.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.john-brandenburg.com"
The down time was caused because php-ppm failed to restart after the system reboot. This wouldn’t have been a problem prior to upgrading to php-fpm 7.2, as I had enabled the service to restart automatically on a reboot. However, trying to do the same with this 7.2 installation didn’t seem to be working. I don’t remember if I had forgotten to enable the service, or attempted to but ran into a problem. Fixing it would normally be a matter of enabling the service again, but when I try to do so, I ran into this error:
# service php72-php-fpm enable The service command supports only basic LSB actions (start, stop, restart, try-restart, reload, force-reload, status). For other actions, please try to use systemctl.
Or with systemctl (since we now redirect over there)
# systemctl enable php72-fpm Failed to execute operation: No such file or directory
It wasn't until later I realized that I had mixed up these commands. I had installed php72-fpm several months ago from the remi repository. I tweeted this out, and my good friend Sidney Harrell responded with:
created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service
enabling any service should do something similar, putting a symlink in that target folder.
Looking at my own system, neither of these directories existed. I’m running Centos 7, so that might just be different from an Ubuntu system (I’m no expert here).
I posted to the remi forum on this, and I got a prompt response from remi. The service I was actually trying to enable was “php72-php-fpm”
# systemctl enable php72-php-fpm Created symlink from /etc/systemd/system/multi-user.target.wants/php72-php-fpm.service to /usr/lib/systemd/system/php72-php-fpm.service.
So it turned out to be a simple fix for a mundane oversight (happens more often than you realize).