Overriding server timeout parameter can create chaos

Overriding server timeout parameter can create chaos

by Pierre Raynaud -
Number of replies: 3

Hi,
We were struck by a bug on the gradelib.php file when we upgraded to 3.5.4 that started a process endlessly looping at 100% CPU every time a user clicked on a quiz ...
Hopefully, it was not in a very popular course so we only had to restart Apache a few times a day.

Even though the bug has been corrected in a weekly build, we are puzzled by the fact that the executed code overrides the server timeout limit.
If it was not the case, each looping process would not have stayed more than 30 seconds in memory.

As a developper myself, I know that bugs will always happen but we should not allow them to take down the whole server by overriding system settings.

There should be a global parameter to limit the core_php_time_limit::raise() function especially when the code can be executed with the web interface. 
What do you think about adding this global parameter and patching the core_php_time_limit::raise() function with this parameter set as default ?

Pierre

Average of ratings: -
In reply to Pierre Raynaud

Re: Overriding server timeout parameter can create chaos

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

...but what would the value be?

Average of ratings: -
In reply to Howard Miller

Re: Overriding server timeout parameter can create chaos

by Pierre Raynaud -

I would let this value to be set in the admin panel as a stuck process can have a different impact depending on the infrastructure Moodle is running on.

Average of ratings: -
In reply to Pierre Raynaud

Re: Overriding server timeout parameter can create chaos

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Generally speaking I think that doing so would be a bad idea. This is present for a reason.


This is rarely used these days as we tend to move things to adhoc or scheduled tasks instead, but in some places it is not easily prevented.


The Gradebook is one such place. Typically if you change the grade structure you need to regrade the affected users. This is a time intensive and complex process.


Ideally this regrade should be moved to an adhoc task but from the time of the change until the completion of the regrade you will have inconsistent grade data displayed.


In addition to this there are still many users out there using the legacy web cron runner. These users MUST allow the timeout to be constantly extended otherwise from jobs will fail part-way through.

Average of ratings: Useful (1)