Could not lock file about analog HOT 5 CLOSED

I would try setting the file manually via:

Analog::handler (\Analog\Handler\File::init ('my_log_file.txt'));

The lock is in place since concurrent requests may try to write to the file at the same time. It's strange that the lock gives you trouble on travis-ci since that's never given me an issue on there...

https://travis-ci.org/jbroadway/analog/builds

If that doesn't do it, you can always create a custom handler based on the File handler that removes the locking.

from analog.

When there are two many requests to access the same file, it throws a lock error because LOCK_NB is specified in line 26 of analog/lib/Analog/Handler/File.php. Remove that like below and it should block while trying to lock the file.

                    if (! flock ($f, LOCK_EX)) {
                            throw new \RuntimeException ('Could not lock file');
                    }

from analog.

@jbroadway I'm already using the code you give to init the file handler, excepting it is part of a multi handler, using something like this:

$run_log = \Analog\Handler\File::init($log_path);
$null_log = \Analog\Handler\Null::init();
Analog::handler(
    \Analog\Handler\Multi::init(
        array (
            Analog::URGENT      => $run_log,
            Analog::ALERT       => $run_log,
            Analog::CRITICAL    => $run_log,
            Analog::ERROR       => $run_log,
            Analog::WARNING     => $null_log,
            Analog::NOTICE      => $null_log,
            Analog::INFO        => $null_log,
            Analog::DEBUG       => $null_log
        )
    )
);

@mta59066 thank you for the pointer :) I guess I should use that in a custom handler based on File one.

I guess I should also disable logging for my unit tests; logging is much more useful for the users who do not have access to syslogs in production environments.

In "normal" conditions, I should not have so many requests to the logger in a few seconds; and I never ran into that issue; running the test that did not happen every time anyway :/

I'll double check my logs call to see if one of them is not called "too frequently".

Thank you :)

from analog.

Looking into LOCK_NB more closely, I believe @mta59066's suggestion to remove it should become the default case. The log file won't be locked for more than a few milliseconds, so blocking isn't really an issue, and we do want to ensure that messages do arrive as expected. Will fix it momentarily.

Thanks for exposing this issue! :)

from analog.

Great, thank you very much @jbroadway and @mta59066 :-)

from analog.