Forwarded to devs Subdomain config update leaves symbolic links in /etc/nginx/plesk.conf.d/forwarding directory

[Bitpalast]

TITLE:

Subdomain config update leaves symbolic links in /etc/nginx/plesk.conf.d/forwarding directory​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx 17.0, latest MU, CentOS 7.2 and 7.3, 64-Bit​

PROBLEM DESCRIPTION:

In several cases on different servers, after a customer has created or updated a subdomain configuration, symbolic links in /etc/nginx/plesk.conf.d/forwarding remain like:

lrwxrwxrwx 1 root root 35 Apr 28 20:23 last_nginx.conf -> admin.customerdomain.tld_nginx.conf

or

lrwxrwxrwx 1 root root 32 May 9 20:42 last_.othercustomerdomain.tld_nginx.conf -> _.othercustomerdomain.net_nginx.conf

These symbolic links are causing a warning message on the Nginx syntax check "nginx -t", because they duplicate existing configurations:

nginx: [warn] conflicting server name "admin.customerdomain.tld" on 88.99.88.99:80, ignored
nginx: [warn] conflicting server name "_.othercustomerdomain.tld" on 88.99.88.99:80, ignored

Duplicate domain configuration files for these domain exist in /etc/nginx//plesk.conf.d/wildcards and /etc/nginx/plesk.conf.d/vhosts along with the /etc/nginx/plesk.conf.d/forwarding versions. Those duplicates cause more warning messages even after the symbolic links are removed manually. This could be related to the same bug, but maybe it is another, additional bug.​

STEPS TO REPRODUCE:

I was unable to reproduce it, but I have seen it randomly on two different servers. It seems to be caused by frequent or high-frequency customer domain updates.​

ACTUAL RESULT:

Redundant / unnecessary symbolic links in Nginx configuration directory.​

EXPECTED RESULT:

No redundant configuration files or links.​

ANY ADDITIONAL INFORMATION:

Reconfiguration, e.g. through Troubleshooter, does not remove the symbolic links. Maybe Troubleshooter is actuall CAUSING the issue. I remember that there were issues when the customers initially created the subdomains, then we used troubleshooter to reconfigure, now we are seeing the extra symbolic links.​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

Hi Peter,

To investigate the issues we need at least panel logs with full enabled debug during the moment when such symlinks appeared.

Required flow:

1. remove all unnecessary symlinks
2. enable full debug
3. When you see that symlinks appeared again - collect panel log.
+ add full paths for this links

Thanks.

 

[Bitpalast]

Question on debug mode: How strong is the impact on server performance? We'd need to run debug mode for a long while to catch this issue. The servers are strong but are hosting many domains. Do you know from experience what the performance impact will be, will it be noticeable by customers?

 

[IgorG]

Peter,
Yes, I think that impact may be noticeable by customers. Especially you need to closely monitor the free disk space. Due to the huge log files on the hard loaded server, it can end very quickly.

 

[Bitpalast]

I have tried to reproduce it by excessive creation and removal of subdomains but was unable to reproduce it yet. The normal panel.log does not give specific hints. I'll need some time to work an idea out how to detect the case when it occurs.