Courier reports: "bind: Address already in use" after upgrade to Plesk 12.5

[iainh]

I am an CentOS 6.7 (Final)‬ fully-patched.

I was on Plesk 12.0.x, fully auto-updated, but today noted an option for 12.5 and so autoupdated to 12.5.30 Update #13 all without error. All looked good following the update. I now realise Courier isn't running and so Email has stopped. The Courier IMAP authentication daemon is/will run.

Tailing /var/log/maillog and either trying to start Courier from the Pleask UI or with
service courier-imapd start I see:

Dec 5 18:01:10 mail courier-imaps: bind: Address already in use
Dec 5 18:01:10 mail courier-pop3s: bind: Address already in use​

A check with ps shows Courier is not running other than the Courier Auth task if I leave that runinng, e.g.

# ps ax | grep courier
15526 ? S 0:00 /usr/sbin/courierlogger -name=courier-authdaemon -pid=/var/run/courier-authdaemon.pid -lockfile=/var/lock/subsys/courier-authdaemon -start /usr/lib64/courier-authlib/authdaemond
15527 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
15529 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
15530 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
15531 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
15532 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
15533 ? S 0:00 /usr/lib64/courier-authlib/authdaemond
16558 pts/1 S+ 0:00 grep courier​

And having looked around before getting to post this, there's no IMAP task being started by inetd or some other task:

[xx@yy]# netstat -tap | grep imap
[xx@yy]#​

or

[xx@yy]# netstat -ntpl | grep 143
[xx@yy]#​

I've looked for obvious altered conf files but so far have failed to find the issue. I've also scoured both on the forums and accross the web for this "Address already in use" error, all without any luck (hence this post). I also found a forum article on 12.0.18 to 12.5.30 problems that suggests Plesk 12.5 is really happier on CentOS 7 making me wonder whether taking the 12.5 upgrade was a big mistake? However, I see no easy regression path :-(

I've checked SELinux settings and they're permissive and so shouldn't be the issue and so I'd be *really* grateful to find out why there is this apparent address conflict and how to resolve it.

 

[iainh]

A few more details:

My version and core.version report as:

12.5.30 CentOS 6 1205151127.16​

Running a bootstrapper repair:

[[email protected]]# ./bootstrapper.sh repair​

it reports:

Bootstrapper repair finished.
Errors occurred while performing the following actions: fix SELinux contexts.
Check '/var/log/plesk/install/plesk_12.5.30_repair.log' and '/var/log/plesk/install/plesk_12.5.30_repair_problems.log' for details.
If you can't resolve the issue on your own, please address Parallels support.
***** problem report *****
Error while setting SELinux types. Command was: restorecon -i -R /usr/local/psa
Error while setting SELinux types. Command was: restorecon -i -R /var/log/psa-horde
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/alias
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/bin
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/boot
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/control
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/plugins
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/popuser
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/queue
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/users
Error while setting SELinux types. Command was: restorecon -i -R /var/db/kav
Error while setting SELinux types. Command was: restorecon -i -R /var/db/Quarantine
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/plesk
Error while setting SELinux types. Command was: restorecon -i -R /usr/libexec/postfix
Error while setting SELinux types. Command was: restorecon -i -R /var/drweb
Error while setting SELinux types. Command was: restorecon -i -R /opt/drweb
Error while setting SELinux types. Command was: restorecon -i -R /usr/lib64/plesk-9.0
Error while setting SELinux types. Command was: restorecon -i -R /etc/nginx
Error while setting SELinux types. Command was: restorecon -i -R /usr/sbin/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/log/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/run/nginx.pid
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/plesk/mail
Error while setting SELinux types. Command was: restorecon -i -R /opt/kav
Error while setting SELinux types. Command was: restorecon -i -R /usr/lib64/php/modules
Error while setting SELinux types. Command was: restorecon -i -R /var/run
Error while setting SELinux types. Command was: restorecon -i -R /var/www/vhosts
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/mailnames
Error while setting SELinux types. Command was: restorecon -i -R /var/named/chroot​

'/var/log/plesk/install/plesk_12.5.30_repair.log' and '/var/log/plesk/install/plesk_12.5.30_repair_problems.log' simply repeat the same messages with no further details.

 

[iainh]

As a further update...

I ran:

# plesk repair mail​

as per the thread 'Plesk 12.5.30 update fail! neeed help' and then had the odd situation of Dovecot running while at the same time Home > Tools & Setting > Services didn't show Dovecot at all! ps confirmed it was though, no matter what 'Services' thought.

So I zipped over to 'Updates and Upgrades' and this too confirmed Dovecot was not installed, but Courier was, so I opted to install Dovecote which simultaneously removed Courier (gulp!). That ran to completion and so then reversed it, installing Courier and removing Dovecote and bingo, I seem to have mail and havne't even lost any mailboxes of mail. I guess all I need to do now is check on my SMTPS/TLS settings...

 

[UFHH01]

Hi iainh,

I've checked SELinux settings and they're permissive and so shouldn't be the issue and so I'd be *really* grateful to find out why there is this apparent address conflict and how to resolve it.

... and seeing the whole lot of SELinux errors, I'm wondering, why you don't consider to disable SELinux in the first place, just to be sure, that this is not the root cause of your issues.

Second, please be informed, that the command "restorecon" is used to restore default security contexts. Please investigate SELinux errors with the help of your audit.log and post the depending parts, if you need help with the investigations.


Changing the mail - software from postfix to qmail and backwards to postfix does fix quite a lot of ( temporary ) failures/issues, as well that changing from courrier-imap to dovecot and backwards to courrier-imap will resolve as well a lot of issues. What ever you change to, be aware that no mail will be lost at all, because these changes never touch the current mailboxes installed on your server!

 

[iainh]

Wow, thanks for the *very* quick response

Well I found a similar thread, albeit about BIND, under 'BIND not starting in PLESK 7.5.4 on CentOS 4.2 server'. So my SELinux policy is set as:

SELINUX=permissive
SELINUXTYPE=targeted​

So while not disabled, it's not enforcing either and nothing has been altered...other than the update of course.

Checking audit.log there is no mention of 'restorecon' at all, and nor is there any mention of 'courier' or 'imap', although the courier issue was about an apparent IP address conflict (Address already in use?), which makes no sense as I could see nothing to conflict does wouldn't seem to be related to SELinux. So I could try and comb the log, but I can't immedaitely see anything. Why wouldn't restorecon appear in the audit.log (/var/log/audit/audit.log)

 

[UFHH01]

Hi iainh,

consider to use the SELinux - commands manually over the command line from your log, to see if you receive a more explaining error message over the command line and as I suggested previously, try to disable SELinux, before doing another bootstrapper repair, or a Plesk self repair since Plesk 12.5 with the command "plesk repair all -y".

You might find as well answers to SELinux issues at "/var/log/dmesg", or at "/var/log/messages".

Troubleshooting SELinux issues is pretty time-consuming and there might be several reasons for issues/errors/problems... so a decent answer to your question can't be given without further investigations and informations.

 

[iainh]

Well ran:

plesk repair all -y​

Similar output to before, but I note each call to restorecon generates the same output:

/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /etc/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/run/nginx.*.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/lib/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/log/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/queue(/.*)? (system _ubject_r:qmail_spool_t:s0 and system_ubject_r:mail_spool_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/control(/.*)? (syst em_ubject_r:qmail_etc_t:s0 and system_ubject_r:etc_mail_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/sbin/nginx.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/tcp-env (system _ubject_r:qmail_tcp_env_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/qmail-smtpd (sy stem_ubject_r:qmail_smtpd_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
Invalid argument​

So errors for nginx and qmail, but... my box has neither nginx or qmail installed! (see attached). Maybe I should yum remove the packages to really make sure they're not there?

So I get:

Error while setting SELinux types. Command was: restorecon -i -R /opt/drweb
Restoring SELinux context on '/usr/lib64/plesk-9.0'​

and then the same error block...

Error while setting SELinux types. Command was: restorecon -i -R /usr/lib64/plesk-9.0
Restoring SELinux context on '/etc/nginx'​

and the same block...

Error while setting SELinux types. Command was: restorecon -i -R /etc/nginx
Restoring SELinux context on '/usr/sbin/nginx'​

and the same block... over and over.

And then to finish:

Bootstrapper repair finished.
Errors occurred while performing the following actions: fix SELinux contexts.
Check '/var/log/plesk/install/plesk_12.5.30_repair.log' and '/var/log/plesk/install/plesk_12.5.30_repair_problems.log' fo r details.
If you can't resolve the issue on your own, please address Parallels support.
***** problem report *****
Error while setting SELinux types. Command was: restorecon -i -R /usr/local/psa
Error while setting SELinux types. Command was: restorecon -i -R /var/log/psa-horde
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/alias
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/bin
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/boot
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/control
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/plugins
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/popuser
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/queue
Error while setting SELinux types. Command was: restorecon -i -R /var/qmail/users
Error while setting SELinux types. Command was: restorecon -i -R /var/db/kav
Error while setting SELinux types. Command was: restorecon -i -R /var/db/Quarantine
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/plesk
Error while setting SELinux types. Command was: restorecon -i -R /usr/libexec/postfix
Error while setting SELinux types. Command was: restorecon -i -R /var/drweb
Error while setting SELinux types. Command was: restorecon -i -R /opt/drweb
Error while setting SELinux types. Command was: restorecon -i -R /usr/lib64/plesk-9.0
Error while setting SELinux types. Command was: restorecon -i -R /etc/nginx
Error while setting SELinux types. Command was: restorecon -i -R /usr/sbin/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/log/nginx
Error while setting SELinux types. Command was: restorecon -i -R /var/run/nginx.pid
Error while setting SELinux types. Command was: restorecon -i -R /var/lib/plesk/mail
Error while setting SELinux types. Command was: restorecon -i -R /opt/kav
Error while setting SELinux types. Command was: restorecon -i -R /usr/lib64/php/modules
Error while setting SELinux types. Command was: restorecon -i -R /var/run
Error while setting SELinux types. Command was: restorecon -i -R /var/named/chroot

Checking the Plesk database using the native database server tools .. [OK]

Checking the structure of the Plesk database ........................ [OK]

Checking the consistency of the Plesk database ...................... [OK]

Checking system users ............................................... [OK]

Checking virtual hosts' file system

There are files or directories with suspicious permissions in the
root directory of the domain 'xxx.org' ................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

There are files or directories with suspicious permissions in the
root directory of the domain 'yyy.com' ...................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair fs -verbose

Repairing web server configuration
Reinstalling SSL certificates ................................... [OK]
Applying the default SSL certificate to all IP addresses ........ [OK]
Repairing server-wide configuration parameters for web servers .. [OK]
Updating the file of sharing passwords and permissions of users
according to actual information ................................. [OK]
Repairing web server configuration for all domains .............. [OK]

Checking the usage of PHP handlers .................................. [OK]

Repairing the mail server configuration
Reconfiguring all domains and mailboxes ......................... [OK]

Restoring DNS server configuration
Synchronizing DNS zones with the DNS server ..................... [OK]

Checking MySQL database servers ..................................... [OK]

Repair databases on available servers ............................... [OK]

Repair database users on available servers .......................... [OK]

Error messages: 0; Warnings: 2; Errors resolved: 0


exit status 1​

xxx.org is a Drupal instal and yyy.com has some protected directories which may be the trigger for those warnings, but note the summay, 0 errors, 0 errors resolved??

 

[trialotto]

@iainh,

You stated:

So errors for nginx and qmail, but... my box has neither nginx or qmail installed! (see attached). Maybe I should yum remove the packages to really make sure they're not there?

The answer is "no". Removal is not necessary if they are not there.

The problem is very likely to be that you had (intendendly or unintendendly) had some qmail and/or nginx installed.

Adjust the selinux settings, as if they are or were never present.

Afterwards, check all selinux settings, since it should not occur that your selinux settings allow nginx/qmail related settings to "linger on" on the system, after removal.

Regards....

PS Get rid of courier, use dovecot, it is more efficient and performant (and well-maintained).

 

[UFHH01]

Hi iainh,

please, what is the output of :

semodule -l​

If you have enabled modules, which exist even that you don't use the depending software, please disable them.

setenforce 0
semodule -d MODULE_NAME
sentenforce 1​

If you would like to downgrade your SELinux policies, just to upgrade them again afterwards, you would use the commands ( just to make sure, that the SELinux plesk module is up-to-date! ):

setenforce 0
semodule -d plesk
yum downgrade selinux-policy selinux-policy-targeted
yum update selinux-policy selinux-policy-targeted
semodule -e plesk
sentenforce 1​

Please run the Plesk self repair afterwards again and report possible errors from your command line, or from your logs.

 

[trialotto]

@UFHH01,

The SELinux plesk modules is not really up-to-date: selinux-policy and selinux-policy targeted packages actually require a higher version than Plesk "wants to use" by default.

However, updating selinux-policy and selinux-policy targeted packages can do no harm, BUT it is also not necessary for @iainh to resolve his issue.

A simple disabling of modules and/or specific settings will be enough.

Regards.....

 

[iainh]

My box is an ISP pre-built image and so I certainly have never install nginx or qmail.

Looking at the output of semodule -l (attached) then there is no mention of nginx, but qmail does appear as 'qmail 1.5.0'. I therefore went to disable enforcement over qmail and got:

# setenforce 0
# semodule -d qmail
libsemanage.semanage_direct_commit: WARNING: genhomedircon is disabled. See /etc/selinux/semanage.conf if you need to enable it.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /etc/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/run/nginx.*.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/lib/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/log/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/sbin/nginx.
/etc/selinux/targeted/contexts/files/file_contexts: Invalid argument
libsemanage.semanage_install_active: setfiles returned error code 1.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /etc/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/run/nginx.*.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/lib/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /var/log/nginx(/.*)?.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/queue(/.*)? (system_ubject_r:qmail_spool_t:s0 and system_ubject_r:mail_spool_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/control(/.*)? (system_ubject_r:qmail_etc_t:s0 and system_ubject_r:etc_mail_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/sbin/nginx.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/tcp-env (system_ubject_r:qmail_tcp_env_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/qmail-smtpd (system_ubject_r:qmail_smtpd_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Invalid argument
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule: Failed!​

So that's not encouraging as it reports 'Failed!' and it's reporting the same complains about 'Multiple same specifications' for nginx which isn't installed.

On the basis of the complaints (again) about nginx I also tried disabling ngnix...even though it's not supposed to exist. This was at least instant and reported:

# semodule -d nginx
libsemanage.semanage_direct_disable: Module nginx was not found.
semodule: Failed!​

This of course just reinforces there is no nginx as per the semodule output, but it does make me wonder then about why i am seeing these 'Multiple same specifications' errors quoting nginx.

Rerunning semodule -d qmail, e.g a sequence of -d qmail, -d nginx, -d qmail, just gives the same output as the first attempt to disable enforcement on qmail.

Running the policy downgrade/update does seem to have solved the nginx issue, but is still complaining about qmail. Full output attached, but in summary:

# semodule -e plesk
libsemanage.semanage_direct_commit: WARNING: genhomedircon is disabled. See /etc/selinux/semanage.conf if you need to enable it.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/queue(/.*)? (system_ubject_r:qmail_spool_t:s0 and system_ubject_r:mail_spool_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/control(/.*)? (system_ubject_r:qmail_etc_t:s0 and system_ubject_r:etc_mail_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/tcp-env (system_ubject_r:qmail_tcp_env_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/qmail/bin/qmail-smtpd (system_ubject_r:qmail_smtpd_exec_t:s0 and system_ubject_r:sendmail_exec_t:s0).
/etc/selinux/targeted/contexts/files/file_contexts: Invalid argument
libsemanage.semanage_install_active: setfiles returned error code 1.
semodule: Failed!​

So maybe a small step forward.

Then running a self repair:

[xx@yy pp12.5.30-bootstrapper]# ./bootstrapper.sh repair > repairOutput.20151206.log
-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.
#​

Full output attached, but it's a little more hopeful now, reporting:

WARNING!
Some problems are found during start service kavehost(see log file: /var/log/plesk/rc_actions.log)​

But no mention od nginx or qmail so maybe making progress

</var/log/plesk/install/plesk_12.5.30_repair_problems.log> does not list any problems from the run today, only entries for 5-Dec. <plesk_12.5.30_repair.log> looks healthier (attached as .txt as this forum doesn't permit .log file uploads) and does end with:

**** Product repair completed successfully.​

That's certainly encouraging! Anything further I should do to validate the install?

 

[iainh]

I'm interested by the comment of moving from Courier to Dovecote. Is there a KB article on that, just to ensure I don't entire ... things up in attempting a move. Dovecote might be better, but there's also the; If it ain't broke, don't try and fix it approach

 

[iainh]

Odd, Outlook now reporting errors, yet is both sending and receiving :-(

Task 'Synchronizing subscribed folders for [email protected].' reported error (0x800CCC0E) : 'Outlook cannot synchronize subscribed folders for [email protected]. Error: Cannot connect to the server. If you continue to receive this message, contact your server administrator or Internet service provider (ISP).'​

 

[iainh]

Well the Outlook issue seemed to be the server, not Outlook or the connection, and although I could send and receive mail okay, folder synchronisation was always giving errors and clearly not working properly as mail wasn't synched across devices.

Noting your comments about; 'better to use Dovecot', I thought I have a look at migrating and found various Perl scripts to do the grunt work. Then I came across 'Migrate from courier-imap to dovecot in Plesk 12. preserving messages' and Igor's comment: "Migration of existing emails goes transparently and automatically. Structure of mailboxes remains the same. You shouldn't worry about it."

Well my goodness, he's absolutely right and there I have been stealing myself for some messy migration. Just how easy can it be? So a HUGE thank you to whoever must had put a considerable amount of work into allowing a switch from Courier to Dovecot by no more than changing the insalled option in Plesk. What a really nice piece of work, thank you

 

[trialotto]

@iainh

It is not "somebody to thank", it is just the case that, in essence, both courier-imap and dovecot are the "frontend" to an identical mail/mailbox structure (in Maildir/mbox format).

Note that changing the "frontend" does nothing to the underlying structure.

Also note that the "mbox" format is supported by almost all normal mail servers, with the exception of the traditional "odd balls" (and you should not use them).

Finally note that courier-imap is (more or less) one of the "odd balls", since it is only aiming at the Maildir format, as opposed to dovecot that is able to handle both formats.

In short and to simplify: if you want some flexibility (of migration amongst others), reliability, compatibility and so on, just stick to dovecot!

Hope the above explanation helps a little bit.

Regards....

 

[iainh]

Thanks @trialotto, I understand all that you say but I was still amazed at just how simple and smooth it was as nothing is (usually) this simple, and that is from about 35 years at this game. Even the official Courier to Dovecot migration advice is more involved requiring a Perl script and reconfiguration of Dovecot to use an 'Inbox' namespace etc. So once in a while, when something goes really nicely, it's good to let those know that put this stuff together and maintain it, that their effortsd are appreciated

 

[ahmet hassan]

The problem is caused by a race condition in nginx init script (/etc/init.d/nginx), which causes the service start attempt to begin before all nginx worker processes are properly shut down. Occasionally, the issue may resurface after an improper startup of Nginx, an operating system upgrade, or packages related to nginx. If it does, a restart of Nginx (with a slight delay between stop and start) will most likely help.

 

[trialotto]

@iainh,

I like that kind of positive attitude!

 

[iainh]

The problem is caused by a race condition in nginx init script (/etc/init.d/nginx), which causes the service start attempt to begin before all nginx worker processes are properly shut down. Occasionally, the issue may resurface after an improper startup of Nginx, an operating system upgrade, or packages related to nginx. If it does, a restart of Nginx (with a slight delay between stop and start) will most likely help.

Thanks for this and the problems did indeed occur after a yum and Plesk update, however, I do not have nginx installed on the box

 

[trialotto]

The problem is caused by a race condition in nginx init script (/etc/init.d/nginx), which causes the service start attempt to begin before all nginx worker processes are properly shut down. Occasionally, the issue may resurface after an improper startup of Nginx, an operating system upgrade, or packages related to nginx. If it does, a restart of Nginx (with a slight delay between stop and start) will most likely help.

@ahmet hassan

This is completely incorrect, for many, many reasons.

Furthermore, if your Nginx is not working properly and start/stop sequences do not work properly, then it is probably the case that

- your system is depleting it´s resources: resource overusage (but not by Nginx),
- your Nginx configuration has been messed up.

In short, there is no relation at all with Nginx.

Regards....