Restarting PHP service from the command line

madebyraygun

As part of our deploy process, we need to restart the PHP process to clear the opcache. Our deploy scripts run as an SSH user, on another host we would typically add the user to the sudoers list just for the systemctl restart php8.2-fpm command. I imagine that’s not the right way to do it with a containerized PHP environment.

I thought I saw some references to a CLI, but I can’t find that now. I see there’s an API which does include a restart_php command, maybe we could use a curl request, but I don’t see any examples on how to use it. For example, what’s my API endpoint? What’s the format for “prefix API requests with your orgId”?

madebyraygun

OK, I tried doing this with curl, using the endpoint I found in my browser network utilities after restarting PHP from the CP. My request is returning a 404, any ideas on a reason why?

(I am able to run this command from another API client with the same credentials 😞)

curl -X POST -v -H "Authorization: Bearer <<token-id>>" https://<<cp-url>>/api/v2/websites/<<website-id>>/restart_php

*   Trying 5.78.114.234:443...
* Connected to <<cp-url>> (5.78.114.234) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=<<cp-url>>
*  start date: Feb 13 20:00:38 2024 GMT
*  expire date: May 13 20:00:37 2024 GMT
*  subjectAltName: host "<<cp-url>>" matched cert's "<<cp-url>>"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://<<cp-url>>/api/v2/websites/<<website-id>>/restart_php
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: <<cp-url>>]
* [HTTP/2] [1] [:path: /api/v2/websites/<<website-id>>/restart_php]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [authorization: Bearer <<token-id>>]
> POST /api/v2/websites/<<website-id>>/restart_php HTTP/2
> Host: <<cp-url>>
> User-Agent: curl/8.4.0
> Accept: */*
> Authorization: Bearer <<token-id>>
>
< HTTP/2 400
< server: nginx/1.25.3
< date: Wed, 14 Feb 2024 23:26:49 GMT
< content-length: 0
<
* Connection #0 to host <<cp-url>> left intact

Adam

Are you confident the websiteId is correct/intact? I just ran the same curl command on a test cluster (with a valid websiteId and auth token) and it was successful.

madebyraygun

@Adam Yes I'm sure the websiteId is correct, I'm able to get a 200 response from another API client on the same machine. It's just the curl command I'm having trouble with.

Are there any API debugging or logging features I could use from the control panel server to see why this particular request is being rejected? I can't find the nginx logs for the API, I feel like that could provide a clue to the problem.

madebyraygun

Using wget with the same token and website ID returns a 200. 🤔

madebyraygun

So this appears to be a quirk in curl, the POST request doesn't automatically include a Content-Length:0 header and wget does. https://stackoverflow.com/a/47426189

So the final, working curl command for me is

curl -d "" -H "Authorization: Bearer <<token-id>>" https://<<cp-url>>/api/v2/websites/<<website-id>>/restart_php