> On 28 Oct 2022, at 2:27 am, Steve <[email protected]> wrote:
>
> Hi Graham, thanks for your response.
> Sorry I wasn't specific enough, I am logging to a single log file using the
> WatchedFileHandler to avoid issues with log file creation and rotation.
> As I understand, writing to a single file from multiple processes could cause
> logs getting mixed up if two processes write at the same time, I couldn't
> replicate it though. I believe that the same could happen if I log to stderr.
> I couldn't find if Apache uses some coordination mechanism for outputting the
> stderr streams of multiple processes to a single Apache error log file.
>
> I am going to log to stderr as it seems to be working for most people but do
> you know of any documentation on how Apache handles this? Haven't found any
> and I would like to read up on it
You would have you dig through Apache source as well as the separate Apache
Runtime library.
The code basically boils down to:
static void write_logline(char *errstr, apr_size_t len, apr_file_t *logf,
int level)
{
/* NULL if we are logging to syslog */
if (logf) {
/* Truncate for the terminator (as apr_snprintf does) */
if (len > MAX_STRING_LEN - sizeof(APR_EOL_STR)) {
len = MAX_STRING_LEN - sizeof(APR_EOL_STR);
}
strcpy(errstr + len, APR_EOL_STR);
apr_file_puts(errstr, logf);
apr_file_flush(logf);
}
#ifdef HAVE_SYSLOG
else {
syslog(level < LOG_PRIMASK ? level : APLOG_DEBUG, "%.*s",
(int)len, errstr);
}
#endif
}
So uses apr_file_puts() followed by a flush.
So perhaps relying on some aspect of OS that when a write is done as a single
string it avoids interleaving.
Do be aware that Apache caps individual log messages at about 8000 bytes. If
you can't loose log message content beyond that, you shouldn't rely on Apache
logging.
Depending on your requirements, you may be better off using log event capture
using services such as Sentry.
Graham
>
> On Wednesday, 26 October 2022 at 17:56:10 UTC-3 Graham Dumpleton wrote:
> Most people would just log to stdout/stderr which means log output gets
> routed into the Apache error log files. Apache's mechanism for handling log
> files when multiple processes are present seems to work fine. If you have
> multiple sites on the Apache server then configure Apache to use different
> log files for each VirtualHost as a way of keeping log files for different
> application separate.
>
> Is there a specific reason you are using Python logging system mechanisms to
> write to distinct log files (if that is what you meant you are doing)?
>
> Note that most issues with using a single log file for multiple processes
> revolve around initial log file creation and log file rotation. In Apache log
> files are initially created from the parent process so there is no race
> condition on creation. It has a means to handle log file rotation as well,
> although many Linux systems rely on log rotate service instead.
>
> Graham
>
>
>> On 27 Oct 2022, at 5:50 am, Steve <[email protected]
>> <applewebdata://4EF4136A-568F-4E1B-8D4E-DE0250470575>> wrote:
>>
>
>> Hi, I am running a Flask app using mod_wsgi and I've been logging to a file.
>> The issue is now I need to run it using multiple processes but multiple
>> processes logging to a file without coordination is not a good idea.
>>
>> Has anyone heard of a success case where they log to stderr with multiple
>> processes? That's the approach that I am hoping to take as other approaches
>> seem too overkill as of right now because they require to spin up some
>> service independent of the Flask app to handle the logs.
>>
>> And another question, does mod_wsgi do something special with opened files
>> with multiple processes? As I have tested logging with multiple processes to
>> the same file and have not found any issues.
>>
>> Thanks!
>>
>>
>>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected]
>> <applewebdata://4EF4136A-568F-4E1B-8D4E-DE0250470575>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/modwsgi/71b85a03-2818-4492-bbe2-b61344746948n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/modwsgi/71b85a03-2818-4492-bbe2-b61344746948n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/modwsgi/7bc2d5da-e26b-44a8-9710-10241f0dfe79n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/modwsgi/7bc2d5da-e26b-44a8-9710-10241f0dfe79n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/9C7F16FA-CCD1-4859-912E-C8C55A2DA5E4%40gmail.com.
