You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a recent update, php7.3 became php7.4 and the php-loop.pl service file wasn't auto-updated.
The subtle result: a rapidly growing number of php-loop.pl forks, eating up all RAM over time.
I see (virtualmin-nginx/php-loop.pl ) that the code takes note of a crash within ten seconds, and sleeps for five seconds as a result.
Suggestion: if there's an immediate crash (under one second? Half a second?), log an error and exit.
Further suggestion, and I honestly do NOT know what I'm talking about here ;) -- looks like somehow virtual-feature.pl -> feature_modify() needs to run after a potential php system version change???
The text was updated successfully, but these errors were encountered:
Good suggestion, I will have php-loop.pl exit immediately if the PHP command doesn't exist because it was replaced by an upgrade.
The underlying issue of the php7.3 command going away isn't one we can easily handle in Virtualmin. You'd need to re-update all your domains to change the PHP version to 7.4 to fix it.
On a recent update, php7.3 became php7.4 and the php-loop.pl service file wasn't auto-updated.
The subtle result: a rapidly growing number of php-loop.pl forks, eating up all RAM over time.
I see (virtualmin-nginx/php-loop.pl ) that the code takes note of a crash within ten seconds, and sleeps for five seconds as a result.
Suggestion: if there's an immediate crash (under one second? Half a second?), log an error and exit.
Further suggestion, and I honestly do NOT know what I'm talking about here ;) -- looks like somehow virtual-feature.pl -> feature_modify() needs to run after a potential php system version change???
The text was updated successfully, but these errors were encountered: