Fabio M. Di NItto napsal(a):
> On 12/04/2012 05:10 PM, Dan Frincu wrote:
>> Hi,
>>
>> Using corosync 1.4.2 (debian backports) and have noticed that if one
>> messes up corosync.conf in the logging section it still works, but not
>> as expected.
>>
>> For example I had
>>
>> logging {
>> fileline: off
>> to_stderr: yes
>> to_logfile: yes
>> to_syslog: /var/log/corosync/corosync.log
>> to_syslog: no
>> syslog_facility: daemon
>> debug: off
>> timestamp: on
>> logger_subsys {
>> subsys: AMF
>> debug: off
>> tags: enter|leave|trace1|trace2|trace3|trace4|trace6
>> }
>> }
>>
>> Used to_syslog twice instead of logfile and to_syslog. Corosync
>> started without any errors, and without any logs.
>
> to_syslog accepts only yes|no. The first entry would set to default (no
> IIRC) and the second one would override the first entry and set it to
> "no" (for sure). Default log file is set to
> /var/log/cluster/corosync.log. If /var/log/cluster doesn't exists, it
> would fail to open the log file (aka no logs again).
>
>>
>> Probably should bail early, maybe do some syntax checking.
>>
>> Just saying.
>
> Patch? ;)
>
> The idea is nice, there is no doubt about it, but it's almost "mission
> impossible" given the complexity (and not just for logging). Not sure
> maybe Jan has an idea how to fix it easily.
Actually ... we are doing most of checking in 2.x. Even the use case
above will behave same (and part of that behavior is probably faulty,
because logfile is by default nothing, so probably when to_logfile is
set to yes, we should really check logfile and display error if nothing
is set). But because in 2.x corosync.conf is +- dump of icmap,
overwriting of values are logical and correct.
Honza
>
> Fabio
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
