• 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

Issue Apache & nginx psa conf problems and DNS

spm

New Pleskian
I just got an alert of a website on a Plesk server crashing, I believe its on httpd with nginx as reverse proxy. Both these are down and giving the following errors when I try to restart them:

Code:
# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: httpd: Syntax error on line 221 of /etc/httpd/conf/httpd.conf: Syntax error on line 5 of /etc/httpd/conf.d/zz010_psa_httpd.conf: Could not open configuration file /usr/local/psa/admin/conf/generated/13690461240.49964400_server.include: No such file or directory
                                                           [FAILED]

Code:
# service nginx restart
nginx: [warn] duplicate value "TLSv1" in /etc/nginx/conf.d/sslv3-disable.conf:1
nginx: [warn] duplicate value "TLSv1.1" in /etc/nginx/conf.d/sslv3-disable.conf:1
nginx: [warn] duplicate value "TLSv1.2" in /etc/nginx/conf.d/sslv3-disable.conf:1
nginx: [emerg] open() "/etc/nginx/plesk.conf.d/webmail.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/zz010_psa_nginx.conf:6
nginx: configuration file /etc/nginx/nginx.conf test failed

Im not aware of any changes made to the server but when I check yum history I could see that the system had run some actions.

Im also seeing some warnings about named in /var/log/messages, restarting that hasn't helped though

Code:
Apr 17 01:02:46 redacted named[15437]: loading configuration from '/etc/named.conf'
Apr 17 01:02:46 redacted named[15437]: using default UDP/IPv4 port range: [1024, 65535]
Apr 17 01:02:46 redacted named[15437]: using default UDP/IPv6 port range: [1024, 65535]
Apr 17 01:02:46 redacted named[15437]: sizing zone task pool based on 4 zones
Apr 17 01:02:46 redacted named[15437]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
Apr 17 01:02:46 redacted named[15437]: reloading configuration succeeded
Apr 17 01:02:46 redacted named[15437]: reloading zones succeeded
 
Try to run this:
Code:
plesk repair web -y

Then restart httpd and nginx again.
 
Try to run this:
Code:
plesk repair web -y

Then restart httpd and nginx again.

Thanks, I then get these errors, I think I know why too..

Code:
2019-04-17 01:41:20.428] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/httpdmng' '--reconfigure-all'] with exit code [1]
[FAILED]
    - httpdmng failed: Execution failed.
      Command: httpdmng
      Arguments: Array
      (
          [0] => --reconfigure-server
      )
      
      Details: [2019-04-17 01:41:15.227] ERR [util_exec] proc_close()
      failed ['/usr/local/psa/admin/bin/apache-config' '-t'] with
      exit code [1]
      [2019-04-17 01:41:16.329] ERR [util_exec] proc_close() failed
      ['/usr/local/psa/admin/bin/apache-config' '-t'] with exit code
      [1]
      [2019-04-17 01:41:17.380] ERR [panel] Apache config
      (15554904750.03722400) generation failed: Template_Exception:
      Warning: DocumentRoot [/var/www/vhosts/redacted.com/httpdocs]
      does not exist
      httpd: bad user name redacted
      
      file:
      /usr/local/psa/admin/plib/Template/Writer/Webserver/Abstract.php
      line: 75
      code: 0
      Warning: DocumentRoot [/var/www/vhosts/redacted.com/httpdocs]
      does not exist
      httpd: bad user name redacted

so the last part its looking in the wrong place for the files. They are actually in /root/vhosts/mysite.com/httpdocs. The server had to be rebuilt a few weeks ago and I guess the main site files were put there (it was rebuilt from a backup). Ive tried moving them to /var/www/vhosts and then doing the repair again but its the same.

What has changed here to cause it to break like this?
 
Also it seems that the plesk admin password doesnt work now and I get this error when trying to reset from the terminal

Code:
[2019-04-17 02:07:08.841] ERR [panel] Call to a member function syncFileSharingUser() on null:
0: /usr/local/psa/admin/plib/api-common/cuAdmin.php:481
    cuAdmin->_chAdminPasswd(string '******', NULL null)
1: /usr/local/psa/admin/plib/api-common/cuAdmin.php:447
    cuAdmin->_cmdSetAdminPassword(array)
2: /usr/local/psa/admin/plib/api-common/cuAdmin.php:262
    cuAdmin->__construct(NULL null)
3: /usr/local/psa/admin/plib/api-common/CuExecutor.php:59
    CuExecutor->execUtil(string 'cuAdmin', NULL null)
4: /usr/local/psa/admin/plib/api-common/CuExecutor.php:130
    CuExecutor->run()
5: /usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php:25
    CliUtilityRunner->run()
6: /usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php:36
    require_once(string '/usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php')
7: /usr/local/psa/admin/plib/api-cli/admin.php:4
ERROR: Error: Call to a member function syncFileSharingUser() on null (cuAdmin.php:481)
exit status 1
 
I think you may have some database inconsistencies due to the restore and maybe some other stuff broke too due to manual modifications.

I suggest you repair your whole installation, please have a look here:
Plesk Repair Utility
 
Also it seems that the plesk admin password doesnt work now and I get this error when trying to reset from the terminal

Code:
[2019-04-17 02:07:08.841] ERR [panel] Call to a member function syncFileSharingUser() on null:
0: /usr/local/psa/admin/plib/api-common/cuAdmin.php:481
    cuAdmin->_chAdminPasswd(string '******', NULL null)
1: /usr/local/psa/admin/plib/api-common/cuAdmin.php:447
    cuAdmin->_cmdSetAdminPassword(array)
2: /usr/local/psa/admin/plib/api-common/cuAdmin.php:262
    cuAdmin->__construct(NULL null)
3: /usr/local/psa/admin/plib/api-common/CuExecutor.php:59
    CuExecutor->execUtil(string 'cuAdmin', NULL null)
4: /usr/local/psa/admin/plib/api-common/CuExecutor.php:130
    CuExecutor->run()
5: /usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php:25
    CliUtilityRunner->run()
6: /usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php:36
    require_once(string '/usr/local/psa/admin/plib/api-cli/CliUtilityRunner.php')
7: /usr/local/psa/admin/plib/api-cli/admin.php:4
ERROR: Error: Call to a member function syncFileSharingUser() on null (cuAdmin.php:481)
exit status 1

You really seem to have a serious issue with your Plesk database. I suggest you contact Plesk support.

You can also read this article here: Unable to complete initial Plesk configuration: Call to a member function syncFileSharingUser() on null

But judging from the amount of issues you're facing I think it's best when Plesk support take a look at your system
 
You really seem to have a serious issue with your Plesk database. I suggest you contact Plesk support.

You can also read this article here: Unable to complete initial Plesk configuration: Call to a member function syncFileSharingUser() on null

But judging from the amount of issues you're facing I think it's best when Plesk support take a look at your system

Cant do plesk support Im afraid, when I input the license key in their support form they say it was purchased from a third party (the hosting firm) and the hosting firm do not offer support with plesk :|

So its down to me to figure it out. I guess I can do server revert to default and reinstall plesk from scratch? What steps should I take this time to make sure problems dont arise again? I did it last time and all I recall doing was following the installation steps, creating a domain and then rsyncing the site files from a backup directory....
 
and you are right about db errors, I managed to get back into plesk dashboard, I can see that there are no Domains at all for some reason and when I try to create a new domain I get this error

Server Error
500
Db_Table_Exception
Unable to find row by field login with value in smb_users table.
 
If you have just the one domain and have trustworthy off site/local backups of everything you need, I'd indeed consider starting with a clean server (!), reinstalling and configuring Plesk and uploading the site again.

Check and double check the downloaded backups before you resort to this. Contents, databases, emails, everything. A crucial aspect of backups is their ability to actually be restored.

As to what to do so that the problems don't arise again... it's hard to say. What triggered the problems in the first place? Was it an OS update, some customization? It would indeed be prudent to establish the cause at this point. Just an observation, if your page was indeed running out of /root/..., that would be a very strange solution to a problem.

If your host doesn't provide Plesk support, you might also consider finding a third party that can do some hand-on work should you need it in the future.
 
If you have just the one domain and have trustworthy off site/local backups of everything you need, I'd indeed consider starting with a clean server (!), reinstalling and configuring Plesk and uploading the site again.

Check and double check the downloaded backups before you resort to this. Contents, databases, emails, everything. A crucial aspect of backups is their ability to actually be restored.

As to what to do so that the problems don't arise again... it's hard to say. What triggered the problems in the first place? Was it an OS update, some customization? It would indeed be prudent to establish the cause at this point. Just an observation, if your page was indeed running out of /root/..., that would be a very strange solution to a problem.

If your host doesn't provide Plesk support, you might also consider finding a third party that can do some hand-on work should you need it in the future.

Thanks, I have safe backups in several locations so I have done a server reset and started with new Plesk again. I have created my domain again and uploaded the files to /var/www/vhosts/mysite/httpdocs now I just need to import the sql dump but I need to reset mysql root password and here I seem to have a new problem, if I follow the normal method of resetting root pw for mysql by stopping it and starting in mysqld_safe mode and making a new pw that said pw does not work when I restart mysqld .
 
I just did the sql dump import with mysql running in safe mode then restarted it normally and my site is back online now, I still cant reset the root pw though. Also it seems that this problem might have been triggered by the hosting company when they tried to apply and security patch as apparently I was running a version of Plesk with a security flaw and that they were unable to apply the fix due to database corruption...
 
@spm, mysql server is controlled by Plesk, there should be no need to try and change the root password by hand or to create the databases manually.

Assuming that you started with a freshly installed server and freshly installed Plesk control panel, the proper procedure to restore your database's SQL dump would be:

- create a customer and create your domain in Plesk
- under that domain (again, using Plesk interface!), create an empty mysql database, together with a new database user and password
- import the database contents, again, you can use the Plesk interface to do that
- adjust your page's code for the new database name, username and password (settings usually found in a configuration file).

Plesk takes over many aspects of the server administration and you should work with it not against it. If you prefer to do thing by hand, an alternative would be to perhaps consider not using Plesk at all.

If you do wish to do both, it's entirely possible to do so, but you do need to know how Plesk integrates with the services running on a server, or you risk breaking your Plesk installation.

Useful documents to refer to would be:

Plesk Migration and Transfer Guide
Plesk Administrator’s Guide

Good luck!
 
Sorry for the lack of responses. The hosting company told me the following:

Thank you for your inquiry. The database user for Plesk is not able to access the database at the moment, though it appears to be running just fine. This might be due to you having re-installed Plesk or how you re-installed Plesk. You can resolve this issue by manually changing the password for the Plesk user in the database to the password in Plesk's password file: /etc/psa/.psa.shadow. The main issue here is, the password in this file does not match what the database expects from Plesk--Plesk is using the wrong password to try and access its data. Unfortunately, this means most of the automatic repair scripts will not be able to work if they need information stored in the database--for example:

# plesk repair db
Unable to connect to database: 1045

You will want to resolve this with these instructions from Plesk since we would not be able share any passwords. I recommend using the manual method as the automatic method was attempted by us and failed. If you have any questions, please use the AccountCenter to reply back to this message, reach us on chat, or on the phone. Please also include any errors, detailed steps to reproduce, or screenshots of the issues you are experiencing.

Unable to access Plesk on Linux: Access denied for user 'admin'@'localhost' (using password: YES)


I have followed the steps in the above url but at step #7 when resetting the pw manually it still wont let me connect even when running with skip-grant-tables on with this error

Code:
ERROR 1045 (28000): Access denied for user 'admin'@'localhost' (using password: NO)
 
Back
Top