• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Can not start Plesk 12.5 - sw_engine failed

VinnyT

Regular Pleskian
This happened completely out of the blue. No changes were made to the system. The funny thing is that I loaded up a backup image from last week and I am having the same issue on that image as well. The panel has been working fine since last night. This is very strange. Anyway here are the logs:

Starting sw_engine service… failed


Logs:

sw-cp-server/sw-engine.log

[23-Jan-2016 03:47:42] ERROR: FPM initialization failed

[23-Jan-2016 23:13:50] ALERT: [pool www] user has not been defined

[23-Jan-2016 23:13:50] ERROR: failed to post process the configuration





sw-cp-server/error_log

2016/01/22 21:49:47 [error] 943#0: *1309 open() "/usr/local/psa/admin/htdocs/robots.txt" failed (2: No such file or directory), client: 198.20.69.74, server: , request: "GET /robots.txt HTTP/1.1", host: "162.243.221.200:8443"

2016/01/22 21:49:47 [error] 943#0: *1310 open() "/usr/local/psa/admin/htdocs/sitemap.xml" failed (2: No such file or directory), client: 198.20.69.74, server: , request: "GET /sitemap.xml HTTP/1.1", host: "162.243.221.200:8443"

2016/01/23 03:47:13 [crit] 943#0: *1329 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /enterprise/control/agent.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8443"

2016/01/23 03:47:13 [crit] 943#0: *1331 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "POST /enterprise/control/agent.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "127.0.0.1:8443"

2016/01/24 00:05:22 [crit] 956#0: *1 connect() to unix:/var/run/sw-engine.sock failed (2: No such file or directory) while connecting to upstream, client: 66.249.85.230, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/sw-engine.sock:", host: "www.curvve.com:8443"



(i checked the file locations and all of those files are there, i’m not sure why they are not found)




/var/plesk/panel.log:

[2016-01-23 03:59:39] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/wpmng' '--user=nlsecurity' '--php=/opt/plesk/php/5.6/bin/php' '--' '--path=/var/www/vhosts/doamin.com/httpdocs' 'user' 'check-password' '' ''] with exit code [1]

[2016-01-23 03:59:39] ERR [panel] Unable to check WordPress admin credentials while reset cache: open /var/log/newrelic/newrelic-daemon.log: permission denied

PHP Notice: Undefined index: SERVER_NAME in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(798) : eval()'d code on line 24

{"err_code":0,"err_message":"Invalid user ID, email or login: '’"}


ALSO -- THIS MIGHT BE IMPORTANT --


Now that I am running php-fpm /PHP 5.6, I have 2 versions of PHP on my server: 5.6 and the base version that is used for plesk. I can start php-fpm using the plesk-php56-fpm service, but I can NOT start the standard php-fpm service (i have never been able to).

systemd[1]: Starting The PHP FastCGI Process Manager...
php-fpm[11342]: [24-Jan-2016 03:20:29] ERROR: No pool defined. at least one pool section must be specified in config file
php-fpm[11342]: [24-Jan-2016 03:20:29] ERROR: failed to post process the configuration
php-fpm[11342]: [24-Jan-2016 03:20:29] ERROR: FPM initialization failed
systemd[1]: php-fpm.service: main process exited, code=exited, status=78/n/a
systemd[1]: Failed to start The PHP FastCGI Process Manager.
systemd[1]: Unit php-fpm.service entered failed state.
systemd[1]: php-fpm.service failed.


I have already tried the following:
'plesk repair all -y'
httpdmng reconfigure --server and reconfigure-all
/usr/local/psa/bootstrapper/pp12.5.30-bootstrapper/bootstrapper.sh repair

NONE of those worked.



Any help would be greatly appreciated.
 
After 6 long hours, I fixed it.

/etc/sw-engine/pool.d/plesk.conf


make sure the contents of this file are:


[plesk]
user = psaadm
group = psaadm

listen = /var/run/sw-engine.sock
listen.owner = sw-cp-server
listen.group = root
listen.mode = 0600

pm = ondemand
pm.start_servers = 0
;pm.min_spare_servers = 2
;pm.max_spare_servers = 8
pm.max_children = 26
pm.process_idle_timeout = 30s
;pm.max_requests = 10

;slowlog = /var/log/sw-cp-server/slow.log
;request_slowlog_timeout = 10s
;catch_workers_output = yes
request_terminate_timeout = 600s

security.limit_extensions = .php .php3

env[PATH] = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

php_value[auto_prepend_file] = auth.php
php_value[error_log] = /var/log/plesk/panel.log
 
@VinnyT,

You have spent six long hours to revert the plesk.conf to it´s original (default) state. In a sense, that is a waste of time.

I would strongly advice you to keep the Plesk installation as simple and as standard as possible.

Regards....
 
@VinnyT,

You have spent six long hours to revert the plesk.conf to it´s original (default) state. In a sense, that is a waste of time.

I would strongly advice you to keep the Plesk installation as simple and as standard as possible.

Regards....

Thank you very much your observation. Your analysis of the situation is astounding. I agree with you, it was a huge waste of time. Since I did not modify the file, it took me a while to find my way there to solve the issue. Perhaps if you had gotten to me sooner with your sarcastic and incredibly useless remarks, you could have saved me a lot of time by just giving me the solution.

Maybe next time.
 
@VinnyT,

First, no personal offense taken, if that was your intention.

I noticed that you have a lot of "non-standard" problems with Plesk, given all the posts on this forum.

In essence, the contents and nature of those posts do indicate to me that you have some misconfigurations and that is adding up to multiple related problems.

In short, I was not being or even trying to be sarcastic: the best advice in these circumstances is "going back to default", i.e. start from scratch with a clean Plesk installation.

Note that I have visited the site curvve.com, your site I believe and (on the one hand) my compliments, looks good and (on the other hand) hints an external cause or issue for all the problems you encounter with your Plesk instance(s).

It can be the case that some of the "security software packages" from external parties do interfere with Plesk and the configuration thereof.

I am not sure whether this is the case in your situation, but it is worthwhile to investigate.

Finally, some small tips or hints:

a) Plesk Panel has it´s own webserver (Nginx) and, if anything is wrong with Plesk Panel, it often has nothing to do with the configuration of the webserver and/or the Nginx instances that are used to serve Apache based domains (i.e. the Apache + Nginx stack uses a different Nginx, Plesk Panel has it´s own Nginx),

b) you posted the following line from the panel.log:

[2016-01-23 03:59:39] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/wpmng' '--user=nlsecurity' '--php=/opt/plesk/php/5.6/bin/php' '--' '--path=/var/www/vhosts/doamin.com/httpdocs' 'user' 'check-password' '' ''] with exit code [1]

and you should be aware of the fact that "user=nlsecurity" is rather uncommon: it is possible to use non-default users, but it is not adviceable (i.e. issues can arise),

c) restarting sw-engine (i.e. sw-cp-server daemon) is not the same as executing an explicit stop and an explicit start afterwards: restarting is less "forcefull".

If any problems are encountered when restarting sw-engine, it is safe to execute the stop command.

If the stop command still results in a running sw-cp-server (just run ps aux | grep sw-cp), you can safely kill the process by executing kill -9 <pid> (to be found with ps aux).

Afterwards, the sw-engine should start normally.

d) if any "pool related" issues occur, a restart of the process in question via the command line will often resolve the issue.

However, if the problems persist, it is often possible (i.e. not the best practice, but it works) to manually delete the relevant sock files and retry the restart via the command line.

In most cases, that works like a charm.

Hope the above helps and/or clarifies something.

Regards....
 
Back
Top