• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

huge 11.5.30 problems can't login can't do anything

Status
Not open for further replies.
Hi,

boot.log file is empty (the file has old date).

mysql.log is the following:

141024 03:01:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141024 03:01:38 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141024 3:01:38 [Warning] option 'innodb-additional-mem-pool-size': signed value 512000 adjusted to 524288
141024 3:01:38 InnoDB: Initializing buffer pool, size = 2.0M
141024 3:01:38 InnoDB: Completed initialization of buffer pool
141024 3:01:38 InnoDB: Started; log sequence number 0 157308342
141024 3:01:39 [Note] Event Scheduler: Loaded 0 events
141024 3:01:39 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
141107 15:30:22 [Note] /usr/libexec/mysqld: Normal shutdown

141107 15:30:22 [Note] Event Scheduler: Purging the queue. 0 events
141107 15:30:22 InnoDB: Starting shutdown...
141107 15:30:23 InnoDB: Shutdown completed; log sequence number 0 158186460
141107 15:30:23 [Note] /usr/libexec/mysqld: Shutdown complete

141107 15:30:23 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141107 15:30:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141107 15:30:24 [Warning] option 'innodb-additional-mem-pool-size': signed value 512000 adjusted to 524288
141107 15:30:24 InnoDB: Initializing buffer pool, size = 2.0M
141107 15:30:24 InnoDB: Completed initialization of buffer pool
141107 15:30:24 InnoDB: Started; log sequence number 0 158186460
141107 15:30:24 [Note] Event Scheduler: Loaded 0 events
141107 15:30:24 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
141110 17:24:32 [Note] /usr/libexec/mysqld: Normal shutdown

141110 17:24:32 [Note] Event Scheduler: Purging the queue. 0 events
141110 17:24:32 InnoDB: Starting shutdown...
141110 17:24:37 InnoDB: Shutdown completed; log sequence number 0 158325555
141110 17:24:37 [Note] /usr/libexec/mysqld: Shutdown complete

141110 17:24:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141110 17:28:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141110 17:28:36 [Warning] option 'innodb-additional-mem-pool-size': signed value 512000 adjusted to 524288
141110 17:28:36 InnoDB: Initializing buffer pool, size = 2.0M
141110 17:28:36 InnoDB: Completed initialization of buffer pool
141110 17:28:36 InnoDB: Started; log sequence number 0 158325555
141110 17:28:36 [Note] Event Scheduler: Loaded 0 events
141110 17:28:36 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
141111 18:56:52 [Note] /usr/libexec/mysqld: Normal shutdown

141111 18:56:52 [Note] Event Scheduler: Purging the queue. 0 events
141111 18:56:52 InnoDB: Starting shutdown...
141111 18:56:53 InnoDB: Shutdown completed; log sequence number 0 158411556
141111 18:56:53 [Note] /usr/libexec/mysqld: Shutdown complete

141111 18:56:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141111 18:57:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141111 18:57:06 [Warning] option 'innodb-additional-mem-pool-size': signed value 512000 adjusted to 524288
141111 18:57:06 InnoDB: Initializing buffer pool, size = 2.0M
141111 18:57:06 InnoDB: Completed initialization of buffer pool
141111 18:57:07 InnoDB: Started; log sequence number 0 158411556
141111 18:57:07 [Note] Event Scheduler: Loaded 0 events
141111 18:57:07 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
 
Sorry, NothernPeak, but you might misunderstand something here....

So for now... to be up-to-date:
You can't login to the Plesk Control Panel and for an investigation after a reboot, you post a single mysql - log and nothing else. Don't you as well have the feeling that there might be missing something in order that people willing to help can investigate the cause of the issue?

At the moment, you left your broken car in front of a supermarket, with a sign on it: Need help. Car is broken. Replaced the radio, but car still doesn't work.
 
this is my problem i can't login to anything to get any sort of log to post to show why its doing it. sorry for the late reply i haven't been very well.
 
i have tried again to get into putty and i get nothing it says access denied so i revealed the password on the server loging by changing the php coding and i have the right password, server address, port and login info but still nothing i can't get into my own server
 
Hi,

Sorry, I really trying to help you investigate this problem.

I enabled debug mode in panel.ini then I rebooted VPS and tried to login to Plesk. Then I copied all log files you asked. See the attached ZIP file. Messages file was 40MB so I copied only records for last 40 minutes.
 

Attachments

  • logs.zip
    21.7 KB · Views: 1
  • logs.zip
    21.7 KB · Views: 1
@NothernPeak:

please add log - entries from "/var/log/plesk/panel.log" "/usr/local/psa/admin/logs/panel.log" "/usr/local/psa/admin/logs/httpsd_access_log" "/var/log/sw-cp-server/error_log and /var/log/sw-cp-server/sw-engine.log" - because you can see at


... that ALL these files might be of interest when investigating errors from the Plesk - Control - Panel and yes, you can certainly shorten logs, because the entries are only of interest during the time, that you actually try to login to Plesk. There is no need to post time - entries which are unrelevant.
 
Hi,

OK, I attached other log files (4).

Thanks in advance,

P.S. A file /var/log/plesk/panel.log doesn't exist.
 

Attachments

  • logs2.zip
    20.5 KB · Views: 1
Hi NothernPeak,

1. Do you use Fail2ban on your server as well? Maybe with the "apache-noscript" - jail? If you use Fail2ban, please turn it off for a moment with the commands:

/etc/init.d/fail2ban restart && /etc/init.d/fail2ban stop

This will first restart fail2ban, so that all your iptables will flush and afterwards you stop fail2ban for further investigations. After performing these steps, please try to relog into your Plesk - Control Panel as admin and post again the logs: "/usr/local/psa/admin/logs/panel.log" and "/usr/local/psa/admin/logs/httpsd_access_log"

Please restart Fail2ban, after all your problems have been solved with the command:

/etc/init.d/fail2ban start



2. Your earlier posted my.cnf is shortened and doesn't contain the whole configuration. Could you please repost the whole file and as well include all files from "/etc/mysql/conf.d/*" as well?



3. For a short time, untill the problem is solved ( !!! ), you might want to change the security feature, that Plesk checks IP - changes:

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "insert into misc values ('disable_check_session_ip','true')"

Please re-change this, after all your problems have been solved with the command:

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "insert into misc values ('disable_check_session_ip','false')"


As well, you might consider to delete all previous saved sessions with the commands:

( login to mysql ) mysql -uadmin -p`cat /etc/psa/.psa.shadow`
( switch to the psa database ) use psa;
( delete sessions from user admin ) delete from sessions where login='admin';
( logout from mysql ) quit


If you changed something in the Plesk - database, be sure to restart your Plesk Control Panel with the command:

/etc/init.d/psa restart

... and retry to login into the Plesk Control Panel.


Please reply with what you did, if you experience further issues/problems and include as well again new logs as you did before, in order to get more suggestions.
 
Hi,

Thanks for you reply!

I have CentOS 6.4 64-bit with software installed by default.

1. There is no fail2ban on my VPS.
Code:
[root@vpsxxxxx /]# /etc/init.d/fail2ban restart && /etc/init.d/fail2ban stop

/bin/bash: /etc/init.d/fail2ban: No such file or directory

2. There is no folder /etc/mysql

File my.cnf was located in /etc and I attach it.

I found /var/lib/mysql folder but there was not /conf.d/ sub-folder inside.

3. The command you asked to performed causes error message:

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "insert into misc values ('disable_check_session_ip','true')"

Code:
[root@vpsxxxxx /]# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "insert into misc values ('disable_check_session_ip','true')"
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

I tried the following advices:
"As well, you might consider to delete all previous saved sessions with the commands:".
And here is the log. Regrettably it didn't help.

Code:
[root@vpsxxxxx /]# mysql -uadmin -p`cat /etc/psa/.psa.shadow`
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 68
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use psa;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> delete from sessions where login='admin';
Query OK, 0 rows affected (0.03 sec)

mysql> quit
Bye
[root@vpsxxxxx /]# /etc/init.d/psa restart
Stopping sw-engine-fpm:                                    [  OK  ]
Starting sw-engine-fpm:                                    [  OK  ]

Should I send you all logs again or wait for further instructions?
 
Hi,

I can't contact Parallels:

1. On this page:
http://www.parallels.com/support/request/
there is no my product (Plesk Panel for VPS on Linux).

2. Chat support is not availble for my license.

3. Skype support doesn't respond.

Let me remind that I have 2 VPS servers with default settings and both servers have now problem with accessing Plesk Panel.

I purchased Plesk Panel license from OVH web hoster.
 
My problem was solved.

Russian text:

Здравствуйте,

На данный момент Plesk интерфейс доступен на обоих серверах.

Я изменил вручную параметр 'login_timeout' в таблице 'misc' в базе данных Plesk, я установил значение 120:

--------------
mysql> update misc set val=120 where param='login_timeout';
Query OK, 1 row affected (0.03 sec)
Rows matched: 1 Changed: 1 Warnings: 0
--------------

Так как интерфейс Plesk доступен, я снижаю критичность заявки до "Нормальная" согласно имеющимся у нас определениям срочности:

http://odin.com/ru/support/form/Plesk_ticket_severity

Проблема вызвана тем, что время в mysql и время в sw-engine отличается на 1 час.

Не связано ли это с переводом времени на 1 час назад в России? Но вручную я не менял время на серверах.

По всей видимости это и является причиной данной проблемы. Насколько я вижу, на данный момент время на серверах отличается от реального времени в Москве на 1 час.

Пожалуйста проверьте настройки времени на серверах. В случае необходимости, Вы можете установить время длительности сессии в Plesk обратно на 30 мин (Server -> Tools & Settings -> Session Idle Time). Как я Вам писал в предыдущем письме, я изменил это время на 120 мин.
 
In English - problem was related to winter time shift in Russia.
 
Status
Not open for further replies.
Back
Top