ApisCP account website (WordPress) has HTTP 503 - Service Unavailable

Any idea what can couse a website in ApisCP to start throwing a HTTP 503 - Service Unavailable error? Error message is:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Doesn’t appear to be an issue with the website itself.

Apache error_log is showing the following whenever I try to refresh the website:

[proxy_fcgi:error] [pid 603735:tid 603758] [client 69.162.124.229:60452] AH01067: Failed to read FastCGI header, referer: http://mywebsite.com
# cpcmd misc:cp-version
revision: bfc3e3eb423bda50780057c42a823ce77a505b70
timestamp: 1733516874
ver_maj: 3
ver_min: 2
ver_patch: 45
ver_pre: ''
dirty: false
debug: false

I checked all resource limits, everything was wide open so don’t think it was any resource usage issue.

Tried restarting httpd, ApisCP, and finally entire VM, this still didn’t fix the issue.

Finally, I ran the following

chown -R 21040:admin1 /home/virtual/myparent.com/home/siteuser/mywebsite.com/

and the website immediately started working.

How do I diagnose/troubleshoot this in the future? None of the logs I had pointed to a permissions issue.

As to why it happened in the first place, is it possible WordPress was editing files (e.g. theme editor) and saving them under the wrong user? Any way to verify this? Sub-user account in ApisCP shows the user account is using the apache user as expected.

Do not operate as root within a vfs. Doing so can create permission anomalies, including these files not transferring over in a server-to-server migration.

Since the mere task of changing owner/group was sufficient, the original group of the PHP file was root or another group other than admin1 with the permissions being 640, i.e. inhibits read by members outside the owner or group.

Modifying these files within WordPress would not change the group as all files created within PHP-FPM are tagged with your group ID.

Thanks for the response. I made no changes/edits on the file system as root or otherwise.

The website was working last night, then this morning it suddenly was not.

The only two impactful things I can think of are:

  • A WordPress user may have modified a file (inadvertently or otherwise) from the WP backend (i.e. add/remove plugin, edit any files via WP’s editor, etc)
  • Some automated part of ApisCP modified files but didn’t chown properly (this seems highly unlikely as only one sub-account/website was impacted.)

Other than the above, there is no other access to modify files. No panel, ssh, or user ftp access.

On a potentially related note, I have seen, that somehow depending on the security/file permissions of a WordPress directory and its files, WP complains about not having the correct permissions to upload plugins or make other changes and to fix the issue, instead asks for valid FTP credentials.

And indeed, in wp-config.php, I see FTP account defined, I’m almost certain was due to this same issue in the past:

define('FTP_USER', 'PARENTaccount@myparent.com');
define('FTP_HOST', 'localhost');
define('FTP_SSL', false);
define('FS_METHOD', 'direct');

Logically, this would almost certainly be an issue because, it would seem when FTP access is used, in whatever situation, the parent account would be used instead of the sub-account.

I wouldn’t think this would result in change of file ownership, even when modifying, but if for any reason, a file is created or removed and readded, then the new owner of those files would obviously be the parent’s account.

This is part of Fortification, which is akin to UAC in Windows or sudo in Mac/Linux. We don’t want any arbitrary, unauthenticated code received from a web request to have deleterious effects. Moreover, keeping separation between what’s deliberate and what’s unauthenticated serves the basis for audits; it’s a separate component that helps you quickly identify foreign files on the site.

I’d recommend keeping it enabled. If you want ApisCP to act like cPanel - and carry the insecurities historic to its ease of use - then go to Web > PHP Pools and change the pool owner to match the account owner. See also SECURITY.md.

For another user to handle the access rights to the account, then under Web > Web Apps > Options, change the owner of the account which includes file ownership change. It does not update the FTP_USER parameter (will address this week), so there is a potential risk the site owner was updated - including permissions - but FTP_USER referred the initial owner at install.

FTP_USER directive is now modified in edge whenever the owner changes.