• 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

StatInfo->getProductVersion failed: file_get_contents() failed:

L

laztrix

Guest
Hi,

After I run plesk updater ( 8.6 to 9.0 ) I got this error:

ERROR: PleskFatalException
StatInfo->getProductVersion failed: file_get_contents() failed: mktime() [<a href='function.mktime'>function.mktime</a>]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead

0: /usr/local/psa/admin/plib/common_func.php3:108
psaerror(string 'StatInfo->getProductVersion failed: file_get_contents() failed: mktime() [<a href='function.mktime'>function.mktime</a>]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead')
1: /usr/local/psa/admin/plib/common_func.php3:66
getProductLoginVersion()
2: /usr/local/psa/admin/plib/sso/SP.php:101
ssoGetSpName()
3: /usr/local/psa/admin/plib/sso/SP.php:393
SsoSpConfig->load()
4: /usr/local/psa/admin/plib/sso/SP.php:215
SsoSpConfig->__construct()
5: /usr/local/psa/admin/plib/sso/SP.php:223
SsoSpConfig::getInstance()
6: /usr/local/psa/admin/plib/sso/SP.php:447
SsoSpConfig()
7: /usr/local/psa/admin/plib/sso/RelyingParty.php:19
isSsoEnabled()
8: /usr/local/psa/admin/auto_prepend/auth.php3:195

How can that be fixed ?
 
Having the exact same problem .. is there no fix for this?
 
Ok, how many posts of this problem need to occur before someone posts a solution?

I'm having this same problem after installing Plesk on a Fedora 8 container.
 
memory issues

I don't recall posting the solution to this exact problem.

However, I had various problems during my initial install. This was one of them. The errors all seemed to stem from memory allocation issues.

You can see these errors with the following command on the hardware node (HN).

Code:
# cat /proc/user_beancounters

I recommend allocating a minimum of 512MB RAM during the upgrade process.

For further information, you can checkout my detailed post here.
http://www.techdruid.com/index.php/component/content/article/40-vps/55-openvz-memory-insufficient
 
Solution: you have to login to psa’s database via MysqlQuery Browser or any other client you want and then the following steps

1) find the domain id, just go to the client of the domain, and in the domain select list,
put your mouse over the domain name, in the status bar of the browser you will see something like:
https://yourserver.tld:8443/domains/dom_ctrl.php3?dom_id=865&previous_page=domains
the domain id there is “dom_id=865″.

2)open the psa database in mysql
3)run: SELECT * FROM SiteApps where dom_id=’865′;
you will see the application in 1 line, then delete it
4)run: DELETE FROM SiteApps where dom_id=’865′;

try again to delete the domain from Plesk.

after that if you receive the error:

ERROR: PleskFatalException
Cannot delete database which is in use by a site application

do the above:
2)open the psa database in mysql
2)run: SELECT * FROM data_bases where dom_id=’865′;
you will see the lines with the databases the domain has,
3)run: DELETE FROM FROM data_bases where dom_id=’865′;

After the 3rd step you will be able to delete the domain from Plesk, just
dont forget to manualy delete the databases (given from step 2)
 
Something like this is usually 2 things:

1. MySQL has blown up, crashed out. This is A Bad Thing.
tail /var/log/mysqld.log for any errors. Get your dedicated server support to help out if it shows anything ugly about db corruption. You're doing regular mysqldumps right?

2. MySQL has become unavailable due to too many connections. Could be queries stacked up for whatever reason. Usually if this is the case you'll get a "Too many connections" error from MySQL, but stranger things have happened.
Get mysqltuner.pl from http://mysqltuner.com/mysqltuner.pl and run that bad boy, which will make recommendations on MySQL config changes.
Set wait_timeout = 600 and interactive_timeout = 600 in /etc/my.cnf to help with weird queries stacking up. Enable slow query logging to see any queries that are causing things to stack up.
 
I just got this on myserver

I found out that /usr/local/psa/version was zero sized but fortunately I have other servers with intact version files so was able to work out the solution

1 Run rpm -qi psa
2 Note down the following...

[Example from my system - yours will differ]
Version : 9.2.3
Release : cos5.build92091016.19

You also need the server type being used - mine being CentOS 5

From this info I was able to rebuild my version file to contain...

9.2.3 CentOS 5 92091016.19 [Yours WILL differ]
 
Thanks for your solution, this also worked for me! For anyone having this problem, this is the first thing they should look into, not only because it's simple, but also because it isn't destructive. If /usr/local/psa/version is 0bytes in size, chances are that's your problem.



The number after "CentOS 5" in the example below is the exact number copied from "Release" after you run rpm -qa psa.


Thanks again!



Erik



I just got this on myserver

I found out that /usr/local/psa/version was zero sized but fortunately I have other servers with intact version files so was able to work out the solution

1 Run rpm -qi psa
2 Note down the following...

[Example from my system - yours will differ]
Version : 9.2.3
Release : cos5.build92091016.19

You also need the server type being used - mine being CentOS 5

From this info I was able to rebuild my version file to contain...

9.2.3 CentOS 5 92091016.19 [Yours WILL differ]
 
Brilliant.. solved my problem too! However updating plesk later from 9.51 to 9.53 seems not to have updated file, I had to do manually to show correct ver INSIDE plesk, however externally the login page shows "log into Plesk 9.5.1" still.. any suggestions what file I need to manually edit to have it say 9.5.3?
 
Just wanted to give my thanks to Simon for posting this fix - this saved my bacon today.

1 Run rpm -qi psa
2 Note down the following...

[Example from my system - yours will differ]
Version : 9.2.3
Release : cos5.build92091016.19

You also need the server type being used - mine being CentOS 5

From this info I was able to rebuild my version file to contain...

9.2.3 CentOS 5 92091016.19 [Yours WILL differ]

Cheers,

Chris
 
Back
Top