Re: SMP: logging

On Tue, 23 Feb 2010 09:03:51 -0700, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/23/2010 07:44 AM, Kinkie wrote:
>> 2010/2/23 Tsantilas Christos <chtsanti_at_users.sourceforge.net>:
>>>> Log rotation will probably need special care to avoid rotating the
same
>>>> log many times. It is relatively easy to designate one process to do
>>>> the
>>>> rotation (e.g., squid1), but that alone is not enough to synchronize
>>>> everything. Ideally, I would prefer to avoid locking. Any clever
tricks
>>>> applicable here?
>>> Maybe something like the following:
>>> - there is a master process
>>> - master process communicates with one direction pipes with kids,
>>> sending
>>> various commands
>>>
>>> For logs rotation:
>>> - master process closes the old file and rename it
>>> - master process opens a new log file
>>> - kids still writing to the old file (because they did not close the
>>> file descriptor yet)
>>> - master process send a command to all kids saying that the log file
>>> rotated
>>> - The kids close the log file and reopen it.
>>>
>>> The above will work at least for unix systems (I do not know about
>>> MS-Windows)
>>> Master/kids communication using pipes is used by the apache worker
>>> server.
>>> I am also using it in my icap server. I am not seeing any problem.
>>
>> Why not just having a log writing helper to whom clients write log
>> lines via some kind of sockets?
>> That would make the log rotation problem just go away - especially the
>> part where there may be race conditions among workers writing together
>> to the same file.
>
> The logging daemon does not make log rotation problem go away. You still
> need to implement log rotation. It just becomes slightly easier to do
so.
>
> The O_APPEND solution, if it works, does not have race conditions among
> workers writing together to the same file. Or, more precisely, we trust
> the file system layer to handle those race conditions.
>
> Please see my earlier email with the same subject for the
> daemon-vs-append comparison summary. I would not be surprised if there
> are more pros and cons to consider here, but so far I do not see enough
> advantages to implement a logging daemon as the default SMP logging
> mechanism.

We already have a logging daemon producing stdin/stdout/stderr sockets to
a master process. We have a TCP multi-input daemon coming. The file daemon
is certainly working swimmingly well here and elsewhere.

All thats needed is to make it the default and...
 a) pass its sockets a little further afield (same as for all other
helpers if we share them).
or
 b) use O_APPEND internally to the daemon so each process sub-child daemon
can write the same log.

The hard bit is cache.log. Though if we go the O_APPEND route thats easy,
if we want everything daemon logged, it should not be too hard to start a
daemon for it and convert debugs() to log there.

Amos
Received on Tue Feb 23 2010 - 21:57:28 MST