Subdomains missing from CP after upgrading to PLESK 10.4.4

[IgoKonrads]

Hi guys,

I have had many problems with plesk upgrades before, but I have always managed to find the solution here, however this time I have not seen anyone posting about this issue yet so thought I should do my first post.

The problem:

After upgrading from plesk 10.3.1 to plesk 10.4.4 I noticed that my subdomains stopped working correctly. Seems the PHP settings have changed and I get errors on all subdomains relating to php safe mode which seems to be switched on. I logged on to plesk to check what the settings are only to find that only 2 of the subdomains are showing under domains list on plesk. All other are missing. I have around 15 domains and most of them had subdomains before.

I logged via SSH and can see that the subdomains are there on the server but PLESK doesn't seem to pick them up.

Also BIND wont start but will do a seperate post for that.

Any ideas where to start troubleshooting this issue?

Kind Regards,
Igo

 

[IgorG]

Looks like related thread? - http://forum.parallels.com/showthread.php?t=208848

 

[Sergey L]

Hi guys,
... only 2 of the subdomains are showing under domains list on plesk. All other are missing. I have around 15 domains and most of them had subdomains before.

I logged via SSH and can see that the subdomains are there on the server but PLESK doesn't seem to pick them up.

Hello, this issue is very similar to the one fixed in
Parallels Plesk Panel 10.4.4 MU #3 [18-Nov-2011]:
[-] No subdomains in Plesk GUI after upgrade.

Regards

 

[IgoKonrads]

Update

Hi,

I just ran the autoinstaller to install all the microupdates but this did not fix the problem, however I noticed that all subdomains were mentioned during the update and this is the error message:

Start upgrade of subdomain sub.domain.tld
Start moving via CLI: sub.domain.tld
Error catched: Unable to acquire semaphore: Empty error message from utility.; #0 /usr/local/psa/admin/plib/api-common/CuExecutor.php(29): AbstractCuExecutor->_execUtil('cuSite', NULL)
#1 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(459): CuExecutor->run()
#2 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(103): SubdomainsUpgrader::_executeCli(Array)
#3 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(252): SubdomainsUpgrader::_transferSubdomainToDomainViaCli(Array, Array)
#4 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(436): SubdomainsUpgrader::_transferSubdomainsToDomains(Array, '2', '19')
#5 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(30): SubdomainsUpgrader::upgradeUnix('2', '19')
#6 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(497): SubdomainsUpgrader::upgrade('2', '19')
#7 {main}
There were problems with subdomain sub.domain.tld
Rollback database changes for subdomain sub.domain.tld

Any ideas?
Igo

 

[IgoKonrads]

Still trying to figure put what the hell is happening here. Anyways, this is the start of the error. Looks like this info may be more helpful than the previous one.

Cmd of subdomains upgrade script exec: /usr/local/psa/bin/sw-engine-pleskrun "/usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php" 2 19
PHP Warning: psasem_lock() failed for semnum 12: semaphore is already acquired; File: /usr/local/psa/admin/plib/api-common/cuDomain.php, Line: 172

Exception: PHP Warning: psasem_lock() failed for semnum 12: semaphore is already acquired; File: /usr/local/psa/admin/plib/api-common/cuDomain.php, Line: 172

file: /usr/local/psa/admin/smb/application/library/Smb/Exception/Syntax.php
line: 55
code: 0
trace: #0 [internal function]: Smb_Exception_Syntax::handleError(2, 'psasem_lock() f...', '/usr/local/psa/...', 172, Array)
#1 /usr/local/psa/admin/plib/api-common/cuDomain.php(172): psasem_lock(12)
#2 /usr/local/psa/admin/plib/api-common/cuDomain.php(105): cuDomain->_processDomainNameCmd('remove', 'sub.domain.c...')
#3 /usr/local/psa/admin/plib/api-common/AbstractCuExecutor.php(21): cuDomain->__construct()
#4 /usr/local/psa/admin/plib/api-common/CuExecutor.php(29): AbstractCuExecutor->_execUtil('cuDomain', NULL)
#5 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(459): CuExecutor->run()
#6 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(141): SubdomainsUpgrader::_executeCli(Array)
#7 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(252): SubdomainsUpgrader::_transferSubdomainToDomainViaCli(Array, Array)
#8 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(436): SubdomainsUpgrader::_transferSubdomainsToDomains(Array, '2', '19')
#9 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(30): SubdomainsUpgrader::upgradeUnix('2', '19')
#10 /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php(497): SubdomainsUpgrader::upgrade('2', '19')
#11 {main}



Please, has anyone got any idea about this?

 

[Kirill K]

IgoKonrads, could you provide ssh access to your server (you may send it in PM)?
If not, please attache autoinstaller log (/tmp/autoinstaller3.log) and sw-cp-server log (/var/log/sw-cp-server/error_log).

 

[SibProgrammer]

Did you try to repeat subdomains upgrade procedure? If not, try again:
/usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/scripts/upgrade_dns_1011.php

 

[IgoKonrads]

SibProgrammer, did you mean
/usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php
?

Anyways, I tried both and no luck. Will send log files to kriogen and see whether someone can finally figure out the cause of this.

Thanks for your replies so far.

Igo

 

[IgoKonrads]

Have sent the log files twice, however don't see the messages in my sent folder so not sure whether the forum messaging is working or not.

kriogen - please confirm you have received.

Regards,
igo

 

[Kirill K]

kriogen - please confirm you have received.

Yes, we received it. Thanks. I will inform you about results of research.

 

[SibProgrammer]

Log files didn't help.

Please provide the output of the command:
PLESK_INSTALLER_DEBUG=1 /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/scripts/upgrade_subdomains_1011.php

Is it empty or do you see some information? Is this information the same after each attempt?

Also please provide the output of the command:
mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e 'select count(*) from subdomains;'

P.S. To save the time you can send temporary access to the server to kriogen and we will check and try to find the root cause.

 

[IgoKonrads]

Hi,

The first command showed me lots of info and will send to you via PM shortly.
Same errors no matter how many times I run it.
The result for second command was "12"

Regards,
Igo

 

[SibProgrammer]

Some strange issue blocks migration of one of subdomains.
Try:
PLESK_INSTALLER_DEBUG=1 /usr/local/psa/bin/sw-engine-pleskrun /usr/locubdomains_1011.php 3 19
This command could help you to migrate other subdomains (if there is no same issue).

 

[IgoKonrads]

Ok did that and some more subdmonais got transfered but not all. Sending you report.
Also the ones that did, still show php errors so settings have not gone back to what they were before.

Regards,
Igo

 

[SibProgrammer]

If subdomain is located at <webspace-root>/dev directory, subdomains upgrade procedure fails. We're working on this issue and maybe the fix will be shipped in the nearest microupdate.

But probably you have no time to wait for the fix. You can change www_root field value for problematic subdomains (see subdomains table) using mysql client.

 

[IgoKonrads]

Thanks you Sib. I have not had a chance to try this yet but definitely will tomorrow. So are you suggesting that if I change the database entries to say /test and then also rename the folder itself to /test aswel, upgrade script should work?

Also, I wanted to ask whether it is ok to always stay up to date with centos repo updates or should I only update the essential stuff? I mean if I update centos packages and later plesk panel, does it increase the chance that plesk upgrade may fail?

Regards,
Igo

 

[SibProgrammer]

Yes, this is what I mean. Instead of renaming I suggest to move content of "dev" folder except "null" file. File dev/null can be used by chroot shell and removing it can lead to other problems. Renaming/moving can be done after upgrade script execution.

As for CentOS updates I can't suggest here. First of all I'm Debian/Ubuntu fan And personally try to avoid updates if they are not really necessary.

 

[IgoKonrads]

Hi Guys,

Just installed the MU5 for 10.4.4

I have some subdomains back now but even for those some are fine and some have messed up read/write folder permissions there fore things like caching don't work. I could go and change the permissions manually to solve this, but that's kinda inconvenient.

Also what do I do about the subdomains that don't show? And the ones that don't show are for instance /1513 /tomato /demo etc so nothing to do with /dev

Good thing is that named starts now which was another problem I had after upgrading to 10.4.4

any further suggestions?

thanks for your help so far.

Igo

 

[SibProgrammer]

I can confirm the problem with custom permissions on subdomains. No solution yet, except fixing them manually. We're working on this problem.

As for problem with still not migrated subdomains. Can you provide the output of the command:
mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "select * from subdomains\G;"

 

[IgoKonrads]

Hi guys,

Thanks for the responce. Here is the output of mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa -e "select * from subdomains\G;"

*************************** 1. row ***************************
id: 2
dom_id: 2
name: dev
displayName: dev
www_root: /var/www/vhosts/domain1/dev
sys_user_id: 1
ssi: false
php: true
cgi: true
perl: true
python: true
fastcgi: true
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 2. row ***************************
id: 3
dom_id: 3
name: dev
displayName: dev
www_root: /var/www/vhosts/domain2/dev
sys_user_id: 2
ssi: false
php: true
cgi: true
perl: true
python: true
fastcgi: true
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 3. row ***************************
id: 6
dom_id: 4
name: dev
displayName: dev
www_root: /var/www/vhosts/domain3/dev
sys_user_id: 3
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 4. row ***************************
id: 10
dom_id: 12
name: dev
displayName: dev
www_root: /var/www/vhosts/domain4/dev
sys_user_id: 11
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 5. row ***************************
id: 11
dom_id: 4
name: tomato
displayName: tomato
www_root: /var/www/vhosts/domain5/tomato
sys_user_id: 3
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 6. row ***************************
id: 13
dom_id: 13
name: dev
displayName: dev
www_root: /var/www/vhosts/domain6/dev
sys_user_id: 12
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 7. row ***************************
id: 14
dom_id: 12
name: portal
displayName: portal
www_root: /var/www/vhosts/domain7/portal
sys_user_id: 11
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 8. row ***************************
id: 15
dom_id: 17
name: dev
displayName: dev
www_root: /var/www/vhosts/domain8/dev
sys_user_id: 13
ssi: true
php: true
cgi: true
perl: true
python: true
fastcgi: true
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: fastcgi
maintenance_mode: false
certificate_id: 0
*************************** 9. row ***************************
id: 16
dom_id: 4
name: update
displayName: update
www_root: /var/www/vhosts/domain9/update
sys_user_id: 3
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 10. row ***************************
id: 17
dom_id: 18
name: dev
displayName: dev
www_root: /var/www/vhosts/domain10/dev
sys_user_id: 14
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 11. row ***************************
id: 18
dom_id: 19
name: dev
displayName: dev
www_root: /var/www/vhosts/domain11/dev
sys_user_id: 15
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0
*************************** 12. row ***************************
id: 19
dom_id: 4
name: oc1513
displayName: oc1513
www_root: /var/www/vhosts/domain13/oc1513
sys_user_id: 3
ssi: false
php: true
cgi: false
perl: false
python: false
fastcgi: false
miva: false
coldfusion: false
asp: false
asp_dot_net: false
ssl: false
same_ssl: true
php_handler_type: module
maintenance_mode: false
certificate_id: 0