On Sat, Aug 11, 2012 at 1:15 AM, Steven Dake <sdake@xxxxxxxxxx> wrote:
> On 08/10/2012 01:46 AM, Andrew Beekhof wrote:
>> As someone that uses libqb to log a metric buttload to files and
>> syslogs on a regular basis... I have to ask "why?".
>>
>> Even prior to libqb, I've never seen anything that would suggest a
>> process was blocked waiting for syslog or a file (and thats with 5 or
>> more processes logging to the same place).
>> Syslog will just start dropping messages if you log too much, so I'm
>> inclined to say you're solving a theoretical problem :)
>>
>> Something to think about.
>>
>
> In the past, the syslog API would block because it sent messages over
> IPC without O_NONBLOCK applied to the file descriptor. When syslog
> daemon got backed up, the syslog API would block, triggering totem timeouts.
>
> At one point, syslog was blocking approximately 1 second per message
> (this was a bug that was fixed).
>
> It was not a theoretical problem in the past. I am not sure about now
> adays - probably depends on how glibc implements syslog presently vs 6
> yeaers ago when threaded logging was introduced. If it still uses a
> blocking fd, then it is needed.
Nowdays I see it easily coping with 40-50 messages a second for long
periods of time, so things have probably improved.
I'm also highly distrustful of threads, they've burnt me too many
times, perhaps thats what pushes me in the other direction :)
>
> At one time I had implemented a non-blocking (IE: O_NONBLOCK) syslog api
> function but that has been removed.
>
> Regards
> -steve
>
>
>> On Fri, Aug 10, 2012 at 1:27 AM, Jan Friesse <jfriesse@xxxxxxxxxx> wrote:
>>> Syslog and file log can block, so it's good idea to use libqb threaded
>>> mode to prevent it.
>>>
>>> Signed-off-by: Jan Friesse <jfriesse@xxxxxxxxxx>
>>> ---
>>> exec/logsys.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/exec/logsys.c b/exec/logsys.c
>>> index 6ed5c4f..ed16bc7 100644
>>> --- a/exec/logsys.c
>>> +++ b/exec/logsys.c
>>> @@ -230,6 +230,7 @@ static int logsys_config_file_set_unlocked (
>>> qb_log_ctl(logsys_loggers[subsysid].target_id,
>>> QB_LOG_CONF_ENABLED,
>>> (logsys_loggers[subsysid].mode & LOGSYS_MODE_OUTPUT_FILE));
>>> + qb_log_ctl(logsys_loggers[subsysid].target_id, QB_LOG_CONF_THREADED, QB_TRUE);
>>>
>>> return (0);
>>> }
>>> @@ -355,6 +356,7 @@ int _logsys_system_setup(
>>> } else {
>>> qb_log_ctl(QB_LOG_SYSLOG, QB_LOG_CONF_ENABLED, QB_FALSE);
>>> }
>>> + qb_log_ctl(QB_LOG_SYSLOG, QB_LOG_CONF_THREADED, QB_TRUE);
>>> qb_log_ctl(QB_LOG_SYSLOG, QB_LOG_CONF_PRIORITY_BUMP, LOG_INFO - LOG_DEBUG);
>>>
>>> qb_log_filter_ctl(QB_LOG_BLACKBOX, QB_LOG_FILTER_ADD,
>>> --
>>> 1.7.1
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss@xxxxxxxxxxxx
>>> http://lists.corosync.org/mailman/listinfo/discuss
>> _______________________________________________
>> discuss mailing list
>> discuss@xxxxxxxxxxxx
>> http://lists.corosync.org/mailman/listinfo/discuss
>>
>
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
