[syslog-ng] Bugreport: Ver 1.9.5 problems with facility/level filtering

[Roberto Nibali]

> Well, nobody can tell, but it should. Timezone handling is not really
> consistent among UNIXes as it turned out (I did not think it is so
> difficult to determine the current offset from UTC)

Yes, the old Vixie cron for example has a lot of code for DST handling 
but it does not work, so you have cronjobs being executed twice or 
never. Thus we tend to have cronjobs running during the day.

> While checking it out again, I've found that I missed the "return" part
> of the return statement. This patch (just committed) should cure that
> issue:

Indeed ;).

> --- orig/src/misc.c
> +++ mod/src/misc.c
> @@ -83,7 +83,7 @@ get_local_timezone_ofs(time_t when)
>    tm = localtime(&when);
>    return tm->tm_gmtoff;
>  #elif HAVE_GLOBAL_TIMEZONE
> -  timezone - (tm.tm_isdst > 0 ? 3600 : 0);
> +  return timezone - (tm.tm_isdst > 0 ? 3600 : 0);
>  #else
>    #error "Don't know how to determine current timezone"
>  #endif

So you can only be off by 1 hour? Well, you know, we will certainly 
contact you again once we get to test the new code. For one customer we 
deploy proxy loghost boxes in various parts in the world and the central 
loghost server is in Zurich. We will definitely holler once this setup 
breaks. But we have not entered the syslog-ng-2 development cycle yet 
internally.

>> So I should not spend time on this issue anymore, right?
> 
> I still expect with some portability issues with this one, I also
> received a related mail in private which I have not read yet.

Thanks for looking into this and a safe journey back home,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc