Repeatedly logged out - serious impediment to working

[Thomas_Beale]

From scanning through the Plesk 12 forum, this issue has been reported quite a few times, and is not generally resolved. It's a really serious problem!

On our instance (Plesk 12 / Debian) I am logged out within 1 or 2 minutes quite often while working on config of the primary website (admin access). The session idle time is set to the 30 min default, and the problem isn't to do with changing IP addresses - the multiple sessions visible all have the same IP address.

This happens so constantly it is difficult do any real work.

Where is the logic of session creation and termination? What do we need to look at to deal with this problem? We have root access.

 

[IgorG]

What sort of output

mysql> select * from misc where param='login_timeout';

?

 

[Thomas_Beale]

The value is 3330. Is that ms, sec, ...?

 

[UFHH01]

Hi Thomas_Beale,

this output is the time in minutes, which doesn't equal your settings of 30 minutes from your panel settings. You might want to choose the commands:

mysql -uadmin -p`cat /etc/psa/.psa.shadow`
mysql> update misc set val=30 where param='login_timeout';

... just to be sure to set the timeout of 30 minutes directly into the database.


Sometimes false summer/winter time settings can result to issues described by the thread-starter Thomas_Beale. Please check your time-settings on your server and make sure as well, that your several PHP.ini's contain your correct time-zone settings and values.



Just a notice to the Parallels Team:
Becaused I re-checked settings done over the Plesk Control Panel, I can confirm, that these settings will have a false storage in the psa - database. Setting of "60" minutes will result in a storage of "val=3630", while "30" minutes result in a "val=3330" after the change. ( PSA version: 12.0.18 / Update #35 on Ubuntu 14.04 ). Setting the value over MySQL directly as suggested in the KB "http://kb.odin.com/124112" are correctly displayed at the Plesk Control Panel in minutes.

 

[Thomas_Beale]

Thanks for this. I've made the change (actually through phpMyAdmin, and BTW, the commands you supply need to specify 'psa' DB). I'll monitor the behaviour over the next 24h and report back.

- thomas

 

[UFHH01]

ups.... sorry... you are certainly correct, Thomas_Beale... the correct commands would be:

mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
mysql> update misc set val=30 where param='login_timeout';

 

[IgorG]

Just a notice to the Parallels Team:
Becaused I re-checked settings done over the Plesk Control Panel, I can confirm, that these settings will have a false storage in the psa - database. Setting of "60" minutes will result in a storage of "val=3630", while "30" minutes result in a "val=3330" after the change. ( PSA version: 12.0.18 / Update #35 on Ubuntu 14.04 ). Setting the value over MySQL directly as suggested in the KB "http://kb.odin.com/124112" are correctly displayed at the Plesk Control Panel in minutes.

Strange. I have re-checked it on two my test servers and can't reproduce this issue. When I set 30 minutes in UI I see:

mysql> select * from misc where param='login_timeout';
+---------------+-----+
| param | val |
+---------------+-----+
| login_timeout | 30 |
+---------------+-----+
1 row in set (0.04 sec)

After changing to 60 minutes in UI:

mysql> select * from misc where param='login_timeout';
+---------------+-----+
| param | val |
+---------------+-----+
| login_timeout | 60 |
+---------------+-----+
1 row in set (0.00 sec)

All works fine for me.

 

[Thomas_Beale]

My impression is that the original problem has gone away, so I think the manual fix, which is easy enough at least for people who have the access, is a good stop-gap. Thanks for the help.
- thomas

 

[Thomas_Beale]

More on this. It was not easy to set the field to the correct value - I originally thought I had set it correctly, but the change did not work. Then our sysadmin tried setting it to 0 and it ended up at 30. The field def in the table is varbinary(2000) which is some sort of binary string thing. i would imagine that Plesk (and humans) think it's a normal integer field, and try to write a normal value, which is read as some kind of binary character string instead, giving rise to the wrong values.

 

[Thomas_Beale]

Update (8 April 2015) - this problem has returned even though we manually fixed the DB value as per posts above. Either Plesk updates or some other recurring process is resetting the DB value for this timeout. This really needs to be addressed.

 

[Joey]

Experiencing same problem in this environment:
OS: CentOS 6.6 (Final), Plesk version: 12.0.18 Update #55