Bug #3884


Restarting Web GUI does not restart PHP-FPM

Added by Moshe Katz almost 8 years ago. Updated over 7 years ago.

Web Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


For some reason (I'm still looking through the logs trying to find out why), PHP-FPM crashed on one of my boxes. Since I couldn't restart the box without interrupting a large non-resumable download that was going through it, I assumed that I could log in with SSH and choose "Restart webconfigurator" to take care of this.

However, running "Restart webConfigurator" does not restart PHP. In the end, I had to go through the source code and find the command to run by hand (which did work).

The code in /etc/rc.restart_webgui and /etc/inc/ should be modified to stop and start (respectively) PHP-FPM along with Lighttpd.

I can submit a Pull Request on Github for this if you'd like. It's a pretty simple fix.

Actions #1

Updated by Ermal Luçi almost 8 years ago

I will put a menu option for this.
The webgui is not the only consumer of php these days.

Actions #2

Updated by Renato Botelho over 7 years ago

  • Status changed from New to Feedback

A new menu entry was added

Actions #3

Updated by Chris Buechler over 7 years ago

  • Status changed from Feedback to New

I'm not sure this should be its own menu item. The vast majority of the time that the web interface gets hung up, it's PHP doing it. As things stand now in 2.2, we've gone from console option 11 fixing virtually all instances of the web interface getting hung (2.0.x and 2.1.x and kill PHP too), to it fixing virtually none. People have come to expect that'll kill off PHP, and for it to be of much use, it needs to do so. We used to not touch PHP at option 11, and it rarely helped anything. It fixes nearly all of the rare hang ups with the web interface in 2.1.x.

What all else would be affected? I can't think of anything where it'd be a big deal, it'd briefly interrupt captive portal and similar, but there's a chance it's messed up anyway if the web interface is, and we're talking a very brief interruption. It's not like people do this all the time, it's a rarely-used last ditch effort.

I'm in favor of removing that new console menu item, and adding that action as part of option 11, unless there's a really good reason not to that I'm missing.

Actions #4

Updated by Ermal Luçi over 7 years ago

In 2.2 there are many things using php-fpm.

While before php would get stuck and probably for other reasons php-fpm treats all of that on its own.
Restarting php-fpm should not be tied to webgui since its not anymore the only consumer.

i.e. check_reload_status expects php-fpm running even though it can recover from it.
Also other services trigger directly to php-fpm.

Actions #5

Updated by Chris Buechler over 7 years ago

True, yeah php-fpm should handle those scenarios on its own.

Let's leave it as is, but fix the menu layout. 8 should move down under 7 on the left half, and 17 should be 16 instead, and under 15 on the right side.

Current option 16 (hidden, just regenerates the console menu) seems pointless since it just re-generates the console menu. Hitting "Enter" without putting in any input accomplishes the same end result. Unless I'm missing something, it should be fine to remove 16 entirely, and move the PHP-FPM restart there.

Actions #6

Updated by Renato Botelho over 7 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #7

Updated by Chris Buechler over 7 years ago

  • Status changed from Feedback to Resolved



Also available in: Atom PDF