Updated: Comment #10
Problem/Motivation
The implementation of the `drupal_set_time_limit` PHP wrapper function actually inhibits the ability for long running processes when invoked the CLI (and potentially via HTTP, though this actually cause HTTP timeouts).
This is because when functions like `drupal_cron_run` are called, the current implementation of `drupal_set_time_limit` assumes that the specified $time_limit provides enough time to complete the execution of the process and when in fact it may not. More importantly, `drupal_set_time_limit` imposes the specified $time_limit when running via CLI and the CLI's environment has an unlimited execution time.
By default, PHP's `max_execution_time` is set to 0 for CLI and should be respected if it is set as such. If the environment's PHP CLI max_execution_time is in fact set to 0, `drupal_set_time_limit` will actually impose a max execution time and constrain the process itself from completing.
Proposed resolution
Adapt the implementation of the `drupal_set_time_limit` to perform a check on the currently set max_execution_time, and if the current maximum execution time is greater then zero, then perform the `@set_time_limit` in which the time limit can be imposed.
Remaining tasks
- Write test
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2212033-6-drupal_set_time_limit_allow_unlimited-D8.patch | 624 bytes | helmo |
| #6 | 2212033-6-drupal_set_time_limit_allow_unlimited-D7.patch | 605 bytes | helmo |
| #4 | 2212033-drupal_set_time_limit_allow_unlimited-D7.patch | 605 bytes | amcgowanca |
Comments
Comment #1
amcgowanca commentedComment #2
markpavlitski commentedComment #4
amcgowanca commentedRe-rolled patch with additional empty line at end of file.
Comment #5
amcgowanca commentedI also think that this patch would apply to Drupal 8 as well, given that D8's implementation is identical.
Comment #6
helmo commentedThen here's a D8 patch to get the ball rolling. As @amcgowanca mentioned the patch applied cleanly to D8, only a shift in line number.
I propose to write $current_time_limit > 0 instead of 0 < $current_time_limit ... but that's just a minor thing.
Comment #8
amcgowanca commented@helmo thanks for submitting!
Comment #9
helmo commentedI expect that this gets a Needs tests tag ... so how could we test this?
From a ... standpoint changing the function name to drupal_raise_time_limit() would make it more clear. I'm not aware of any usecase for lowering the time_limit but that could be a separate function.
Comment #10
markpavlitski commented@helmo, at the moment this function doesn't ensure the limit is raised, only that it's not changing from 0 (unlimited) to something else. i.e.:
Would result in a limit of 30, not 300.
Also, what is the purpose of this check?
Comment #11
markpavlitski commentedRestoring related issues.
Comment #12
helmo commentedComment #13
markpavlitski commentedThe name change makes sense, as long as that's what it does. I.e. you can increase the limit or set to zero.
Agreed that test a test case should be included.
Comment #14
markpavlitski commentedComment #15
damienmckennaThis is a duplicate of #174617: Environment::setTimeLimit() ignores current value, can reduce timeout value.