• 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
  • Please beaware of a breaking change in the REST API on the next Plesk release (18.0.62).
    Starting from Plesk Obsidian 18.0.62, requests to REST API containing the Content-Type header with a media-type directive other than “application/json” will result in the HTTP “415 Unsupported Media Type” client error response code. Read more here

Forwarded to devs Intermittent webmail subdomain failures despite correct configuration files and webmail settings

Bitpalast

Plesk addicted!
Plesk Guru
TITLE:
Intermittent webmail subdomain failures despite correct configuration files and webmail settings
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Onyx 17.8, CentOS 7.5
PROBLEM DESCRIPTION:
On one host of ours the web server seems to "forget" the webmail subdomain configurations once in a while. Other subdomains and all main domains do not seem to be affected. A simple "service nginx reload" and "service httpd reload" fixes the issue.​
STEPS TO REPRODUCE:
Unclear. It just happens. There is no indication in log files. The "webmail" subdomains simply do not react and all requests to any webmail subdomain are served by the web server's default page.​
ACTUAL RESULT:
Webmail subdomains suddenly redirect to web server default page despite correct configuration files and previously stable operation in an unchanged configuration.​
EXPECTED RESULT:
Stable webmail subdomain accessibility.​
ANY ADDITIONAL INFORMATION:
Not a DNS issue. DNS is done externally and working correctly (resolving webmail subdomains correctly). Not a fail2ban issue. The webmail configuration files are in place where they always are, webmail program is selected correctly. There is no indication why the web server no longer processes webmail subdomains. The only solution we currently have is to reload the server configuration.

This bug report is only to document the issue. There is probably nothing that can be done about it at this time, because not enough log data or further analysis is available.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Help with sorting out
 
Have no idea how to investigate such case even without access to the server.

Maybe previous reload was in the process of generation of configuration files... Please, tell me a number of domains hosted on the server and correlation with changes of configuration of some domains.

Thanks
 
Currently that host serves 923 domains including subdomains.

The last change to the webmail configuration file of an account where I know for sure that the issue existed was June 21st, while there have been several reloads since then and webmail was working since then. I could not find a correlation with reloads or updates to configuration files.
 
The following information, obtained at the moment when the problem appears, may be helpful (watchdog rules may be adjusted to collect it before restart)
The aim is to see state of worker processes, scoreboard, and actual config. Modules may be configured through "Additional directives for HTTP" for some domain, access should be limited to e.g. localhost.
 

@Peter Debik

Is one of the following symptoms

- it sometimes seems to be the case that css is not loaded
- every now and then there is a blank screen with a =) on the page
- one has to reload webpages and every now and then, the web page loads correctly or slightly better

present?

If so, please let me know, I had a similar set of symptoms, very likely to be related to a plesk package not installing properly.

Regards......
 
No, none of them. Only as described the webmail subdomains. Nothing else. Everythings works beautifully.
 
From developer:

Certainly it is worth to inspect logs of webserver for particular virtual hosts and global one in /var/log/httpd/error_log.
Lower level errors may be in journalctl output.

Wild speculation. A customer hit an issue with dbus (version packed in centos-7.5). There was no direct complain concerning availability of sites, but from journalctl I may expect such consequences. Check logs for org.freedesktop.login1 or systemd-logindmessages.
 
Back
Top