log_threshold > 0 hangs on 1and1 hosted webserver

Hi all,
I hope you can help this new boy?
I am trying to run up a CI application on a 1and1 Linux host. I have it running fine on my local Ubuntu XAMPP environment.

To test, I have put up CI 3.1.6 on the hosted service but it is behaving very oddly.

If I configure log_threshold to anything greater than 0 then the "Welcome to CodeIgniter" just "hangs" - as far as I can tell, nothing is returned to the browser and eventually there seem to be some timeout which get reported as ERR_INCOMPLETE_CHUNKED_ENCODING.

What is more confusing is that reverting log_threshold = 0 does not, immediately, restore the test to a working condition. I am really not sure at what point it starts working again. 

Any thoughts on why log_threshold might not work?
Any thoughts on why reverting the change does not take immediate effect?

FYI: I think you can run phpinfo on this test at http://jakitservices.co.uk/phpinfo.php
(The host supplied PHP as 7.0.24).

In this environment, .htaccess is not required when it works.

Many thanks for any assistance,
 - jon

Make sure that the path defined in $config['log_path'] has write permission.

Any thoughts on why log_threshold might not work?

log_threshold is a simple value; it doesn't work or not work, it just ... exists.

However, what this value represents is what gets logged and that's nothing at 0 and various other stuff otherwise. If your app hangs at any non-0 value, that means it hangs whenever it tries to log anything, so what doesn't work is actual logging.

There's a number of reasons why logging can fail, but if it hangs, that's most likely because CI was unable to obtain a lock for the log file (as it would just wait until it can). If you don't know what a lock is - it is necessary to avoid race conditions where two separate processes write to the same file, or read from it while it is being modified, etc. You should be able to imagine the possible consequences of those situations, but in short: locks prevent data corruption.

Now, unless you've opened the log file via another program while waiting for it to be written, and given that you consistently reproduce the issue, it is very unlikely that there's an actual lock obtained from another process. Likely the file-system itself doesn't allow it - some file systems don't even support locks (FAT comes to mind, IIRC), or some system feature is preventing them (Windows and its stupid "fast boot" actually doing a hybernate) ... Too broad to guess about, you just have to look into it.

Any thoughts on why reverting the change does not take immediate effect?

OPcode cache.

Basically, PHP will cache the compiled state of scripts, so that it doesn't need to repeat that same operation every single time when it can directly execute the compiled program and give you a speed boost.