Getting "Not a main domain of subscription" in WordPress / mail_outgoing_restore

[Sander V]

I recently upgraded to Plesk 12.0.18 (currently MU #10) from Plesk 11.5.

Two problems arose:

1) In WordPress Toolkit, I'm getting the exception "Not a main domain of subscription".

2) Outgoing mail control is not working correctly, I have to keep it disabled or nobody will be able to send e-mail from the server.

Those two problems may or may not be related to eachother.

This is because for problem 2, after some searching, I tried a bootstrapper.sh repair (no errors, except for some MySQL users not related to Plesk) and a mchk. The latter yielded a mail_outgoing_restore error, the same as in problem 1.

It seems to be some database inconsistency, because when I copied the PSA database to a VM with a fully working Plesk, the same error appeared. But where is that inconsistency?

 

[Sander V]

Resolved it. The error message was exactly what it was: in the Plesk PSA database, there was a subscription record that pointed to a domain record that was actually a subdomain.

After I removed this subscription record, the WordPress Toolkit did not produce an exception again.

Running the mchk utility went without a hitch, too. Outgoing mail now works and another problem that surfaced (I could not make e-mail adresses) has now disappeared too.

Maybe this check can be added to the Plesk Integrity Checker script?

 

[burnley]

Hi Sander V, we're facing the very same issue. How did you isolate that dodgy record? In our database, all the domains with corresponding object_ids in Subscriptions table have parentDomainId=0.

 

[Sander V]

It has been a while, but are you sure there aren't any domain records with a parentDomainId NOT zero?

This worked for me: SELECT * FROM `domains` WHERE parentDomainId != 0 and id in (select object_id from Subscriptions where object_type='domain')

 

[burnley]

mysql> SELECT * FROM `domains` WHERE parentDomainId != 0 and id in (select object_id from Subscriptions where object_type='domain');
Empty set (0.00 sec)

There aren't...

 

[burnley]

Just quickly following up on this: using http://kb.odin.com/en/120101 I've enabled debugging and it turned out we had a domain that was causing the issue. Luckily it was a legacy, unused entry and removing it fixed the problem. Although we still don't know what was causing the issue.
Thanks Sander V