• 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

Apache sometimes fails to restart

Thank you. I have forwarded it to developers. Let's wait their reply.

BTW, according to already submitted bug this problem has been fixed by Microupdate #9 - http://download1.parallels.com/Ples...nel-10-linux-updates-release-notes.html#10119

There was an issue with Apache taking one minute or longer to restart. I believe this was addressed but Apache still takes a few seconds to restart. Therefore is not a graceful restart. This is an issue when using web pages which access the API.
 
From the WHMCS forum

I don't know how many people reading this forum are using WHMCS or other billing solution that does API calls to plesk for provisioning but, If someone has found a way to make it work, I would love to hear about it.

WHMCS as with most billing solutions has to send an API call to plesk to setup accounts. Since plesk 10 restarts the webserver immediately, the billing software never gets to hear the response to the API call because it just got reset!!

I just opened a ticket with Parallels on this issue and I can't believe their ridiculous answer.

I was told that doing a graceful restart on apache wasn't safe nor reliable and doesn't even work on all operating systems. YEAH SURE! I was told that there are NO plans to change this in the future.

So while trying to find a workaround. I attempted to modify apachectl and/or /etc/init.d/httpd so even a restart does it graceful. But to my dismay, I discovered that plesk doesn't use those to do the restart.

Has anyone found a way to circumvent this ridiculous behavior?

the post is located here:
http://www.webhostingtalk.com/showthread.php?p=7328892#post7328892
 
My problem which is centered around this same issue has not been solved. It's not 3 days since all the domains on 1 server has gone down. All we did was to upgrade from Plesk 10.0.1 to Plesk 10.1.1 then this **** happened.
 
In the Services Management section you may find that Apache is flagged as not running (even though it is). Also anything that requires Plesk to restart Apache (like creating protected directories) will no longer work until you manually restart apache. Kind of a trade off. But I did what you did for the same reasons. Now WHMCS works for me.

Yeah it is a trade off but when it comes to customers seeing a blank screen I would much rather have to manually run websrvmng lol.

Quote:
I don't know how many people reading this forum are using WHMCS or other billing solution that does API calls to plesk for provisioning but, If someone has found a way to make it work, I would love to hear about it.

WHMCS as with most billing solutions has to send an API call to plesk to setup accounts. Since plesk 10 restarts the webserver immediately, the billing software never gets to hear the response to the API call because it just got reset!!

I just opened a ticket with Parallels on this issue and I can't believe their ridiculous answer.

I was told that doing a graceful restart on apache wasn't safe nor reliable and doesn't even work on all operating systems. YEAH SURE! I was told that there are NO plans to change this in the future.

So while trying to find a workaround. I attempted to modify apachectl and/or /etc/init.d/httpd so even a restart does it graceful. But to my dismay, I discovered that plesk doesn't use those to do the restart.

Has anyone found a way to circumvent this ridiculous behavior?
the post is located here:
http://www.webhostingtalk.com/showth...92#post7328892

If this is true it is the end of the API in Plesk then surely? Because there is no way to execute a php script calling the API without it crashing, Plesk need to sort this ASAP.

Oh btw, there was an upgrade today, not sure what it was but in desperation I ran it (after renaming websrvmng back obv) and it said it was replacing websrvmng but it STILL is not working, so i renamed it back :p
 
Found a Fix on WHMCS forum

Someone posted this on the WHMCS forum and it worked for me.

I researched the purpose of websrvmng and it seems that it is only to give plesk the ability to call the httpd init script for start/stop/graceful/reload/and status.

Since the problem is that Plesk misues it to do hard restart s when we don't want hard restarts, I have replaced this with something that can only do graceful

So, replace your websrvmng with a perl script like this...

#!/usr/bin/perl
system("/etc/init.d/httpd graceful");

And of course chmod to 755 same persmissions and mode as previous websrvmngp
 
I can say this definatly works and is a perfect fix for this problem! Thanks deltatech from webhosting talk!
PHEW!
 
I tried the perl script solution. The only problem is plesk is unable to do the websrvmng --reconfigure-all or similar functions to create vhost conf files. I could see this being an issue, although I could use the event manager to run the commands on an original copy websrvmng. These solutions all suck though. I wish it would just work.
 
I was having problems getting a newer site to display properly. Was getting lots of 404's.

I used a patched script from the knowledgebase and got the following error when doing a reconfigure-all:

Details: Empty error message from utility.
websrvmng: /usr/local/psa/admin/bin/httpdmng execution failed:
2011-05-11T20:22:57-07:00 ERR (3): Apache config (13051705770.11788100) generation failed: Can not restart web server

I went back to my original before the perl scripts and such, worked fine. This one will still nuke our apache, but it seems like something has modified it specifically for my server, which makes it so hard to debug I assume.

Is anyone else out there using magicspam?
 
---------------------------------------------------------------
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

LATEST Plesk 10.2.0 RedHat el5 1011110331.11, CentOS 5 x64 (CloudLinux Edition, note these CloudLinux mods have been disabled and my problem still exists)

PROBLEM DESCRIPTION AND STEPS TO REPRODUCE

Do anything inside the control panel. The web server manager has to be running for a few minutes and serving up a tiny bit of anything otherwise there are no connections for the restart to hang on.

ACTUAL RESULT

The web server manager tool fails at restarting apache, apache dies and has to manually be restarted.

EXPECTED RESULT

A simple restart of apache.

ANY ADDITIONAL INFORMATION
--------------------------------------------------------------
I dont see this every time, but I have seen it occasionally:

[Tue May 10 14:20:25 2011] [notice] mod_python: Creating 4 session mutexes based on 50 max processes and 0 max threads.
[Tue May 10 14:20:25 2011] [notice] Apache configured -- resuming normal operations
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (43)Identifier removed: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [emerg] (22)Invalid argument: couldn't grab the accept mutex
[Tue May 10 14:20:30 2011] [alert] Child 192658 returned a Fatal error... Apache is exiting!
[Tue May 10 14:20:30 2011] [emerg] (22)Invalid argument: couldn't release the accept mutex

--------------------------

Is anyone on Plesk 10.2 and still having this problem? Is anyone running CentOS 5 x64 that can send me a working websrvmng tool (if one exists)?
 
ShoneA,

Thank you for detailed report. I have forwarded it to developers. I will update thread with results of investigation as soon as I receive it.
 
Is there anyone out there who is still having this problem, or maybe has solved it with an update? We're fully updated here and still having the problem and wondering why this thread has calmed down so much.

Edit: After some research we've learned that apache is hanging on SSL connections only. We're going to work on integrating Nginx to proxy SSL so apache wont have to deal with it anymore. Not the easiest solution, but we're betting it'll work after that.
 
Last edited:
Plesk 10.2 then same feaking problem....


Plesk is killing apache when some change are done on the panel (not all time) , then apache did not restart whit same error as first post....

What are you waiting Parallels to correct this !!!!
First post are from November and problem still exist in 10.2 !!!


Each time that require manual intervention or a server reboot !
 
And i have to say thats a new server whit 10.2 (not upgraded but brand new build rhe5) .....
 
Please, try the attached file. It is almost the same as vanilla Plesk 10.2 with one difference - during apache restart, it calls /root/websrvmng_afterstop when apache is supposed to be fully stopped before starting it again.

This script receives a single argument normally set to 1 or in case of error, to 0. It should be used to gather information about what is left running and prevents the apache from starting. An example script is also attached.

http://download1.sw-soft.com/Plesk/Autoupdate/websrvmng-10.2-debug.tar.bz2
 
Hi Igor,


I have not waited since i have alreadyu website on it,

but i have used Sim monitor to fix that until parallels fix it may be onre ady i hope...
I just see there is an update on plesk 10.2 hope that will fix...

Here the log when restarted thats websrvmng that hang;

un 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14637 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14640 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14642 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14643 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14646 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14647 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14649 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14651 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14652 Jun 3 17:39:49 myserver websrvmng[14426]: send_signal_field(): successfully killed 14653 Jun 3 17:39:49 myserver websrvmng[14426]: 22 /usr/sbin/httpd processes are killed Jun 3 17:39:52 myserver websrvmng[14426]: delayed_restart_daemon() restarted Jun 3 17:39:52 myserver websrvmng[14426]: set_restart_status() - last_restart=1307140792, interval=300, pid=0, restart_needed=0; written=1307140792 300 0 n Jun 3 17:39:52 myserver websrvmng[14426]: unlock_restart_status() closing=yes Jun 3 17:39:52 myserver websrvmng[14426]: delayed_restart() sleeping child died (for interval=300, restart.needed=0, restart.interval=300)
 
Hello sergius,

Is this fix supposed to address the issue mentioned in this thread?

After applying this suggestion on Ubuntu 10.04 with the latest Plesk 10.3.1 the issue still persists. However now rather than just being slow on this phase - it fails to restart Apache in general. I'm guessing that there is some intermediate stage where the config files are not correct, and that Plesk sometimes attempts to restart apache while this faulty config is in place.

Without this "fix" installed we do get the error, but apache is automatically restarted and end users do not notice any downtime - so in our case this suggested KB article actually makes things worse.

Cheers,

Merlijn
 
Back
Top