RE: [syslog-ng] Bugreport: Ver 1.9.5 problems with facility/level filtering
The latest snapshot having the fix is always at most 24 hours later. So you might want to download the latest snapshot again today and verify your findings. I don't have time to do it right now but it would be perfect if you could spare some minutes and try again with the newest snapshot drop.
Best regards, Roberto Nibali, ratz
I tried the latest snapshot of syslog-ng, but it fails to compile the initial module. I get: misc.c: In function `get_local_timezone_ofs': misc.c:83: error: structure has no member named `tm_gmtoff' Bottom line... I'm unable to test the facility/level fix because I can't get a clean compilation on the latest version. Sorry. Marvin
I tried the latest snapshot of syslog-ng, but it fails to compile the initial module. I get: misc.c: In function `get_local_timezone_ofs': misc.c:83: error: structure has no member named `tm_gmtoff'
Hmm, this is a BSD extension, and IIRC you are using a BSD system, aren't you? I don't have access to a BSD system right now, but could you check your /usr/include/time.h to see if the struct tm provides this member? Also maybe if you have nothing else to do, could you try following (might not help anything at all) patch?: --- syslog-ng-1.9.5+20051003/src/misc.c 2005-10-03 00:11:46.000000000 +0200 +++ syslog-ng-1.9.5+20051003-ratz/src/misc.c 2005-10-03 20:11:24.979218306 +0200 @@ -34,6 +34,9 @@ #include <pwd.h> #include <grp.h> #include <stdlib.h> +#ifndef _BSD_SOURCE +#define _BSD_SOURCE +#endif #include <time.h> GString *
Bottom line... I'm unable to test the facility/level fix because I can't get a clean compilation on the latest version. Sorry.
Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On Mon, 2005-10-03 at 20:14 +0200, Roberto Nibali wrote:
I tried the latest snapshot of syslog-ng, but it fails to compile the initial module. I get: misc.c: In function `get_local_timezone_ofs': misc.c:83: error: structure has no member named `tm_gmtoff'
Hmm, this is a BSD extension, and IIRC you are using a BSD system, aren't you?
I've added a simple configure check on tm_gmtoff and if it does not exist I fall back to the global "timezone" variable. It should be available in the yesterday's snapshot. -- Bazsi
I've added a simple configure check on tm_gmtoff and if it does not exist I fall back to the global "timezone" variable.
But does the DST handling work correctly in this case?
It should be available in the yesterday's snapshot.
So I should not spend time on this issue anymore, right? Thanks and best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
On Thu, 2005-10-06 at 21:12 +0200, Roberto Nibali wrote:
I've added a simple configure check on tm_gmtoff and if it does not exist I fall back to the global "timezone" variable.
But does the DST handling work correctly in this case?
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) 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: --- 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 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. -- Bazsi
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
participants (3)
-
Balazs Scheidler
-
Marvin.Nipper＠Stream.com
-
Roberto Nibali