negative numbers
2013-07-12 by Rudolf Gabler
Hi all,
first thank you for many replies. I summarize here a little but first the background:
a) I'm using milter-greylist since (at least) more than 10 years without any problems; now on a cluster of Centos 5 system. The error occurred when I updated the distribution package to the actual one (which is milter-greylist-3.0-2.el5.rf under Centos 5).
b) Than I fetched the actual 4.4.3 tar and made a manual compile with the same issue.
c) I switched over to a test system and tried to gdb the problem. I recognized that this issue is seen when the greylist.db is parsed and reloaded by yyparse under help of pending_get
(in dump_yacc.y and pending.c)
d) the main work for that is done in dump_yacc.y and I tried to compile without bison but byacc and with bison, I also used the flex package --- no difference.
e) the actual greylisting records are reported with correct date, so my concern was, that older records (after a restart) are treated incorrect.
f) Let's see one record:
2702:f8b0:400e:c01::232 <bastian@...> 1373100158 # 2013-07-06 10:42:38
as in greylist.db
Jul 11 10:33:50 mailer milter-greylist: created: 2702:f8b0:400e:c01::232 from to <bastian@...> delayed for -119:-51:-12
is reported after the restart.
The greylist.db seems to be o.k. , the report not.
g) Date and Time are double checked (ntpd based - this was also my first guess).
Now the responses
-----
Is everything okay with your system and/or milter-executing user
account clock/timezone? In the database file typically named like
/var/milter-greylist/greylist.db you can see the timestamps in
plaintext; do they make sense related to your system's current
time?
HTH,
account clock/timezone? In the database file typically named like
/var/milter-greylist/greylist.db you can see the timestamps in
plaintext; do they make sense related to your system's current
time?
HTH,
Rudi: Yes as explained above (point f)
----
Please provide more information on the system and environment you are using.
What OS? Version?
Package from a distribution (which?) or compiled from source?
Looks like a byte-order problem or a library/header include file mismatch (regarding
the the type or size in case of parameter or return value passing) to me …
What OS? Version?
Package from a distribution (which?) or compiled from source?
Looks like a byte-order problem or a library/header include file mismatch (regarding
the the type or size in case of parameter or return value passing) to me …
JK
Rudi: Information (OS,Version) see above.
----
You are certain your systel clock did not have been wandering in the
future, then reset?
future, then reset?
Emmanuel Dreyfus
Rudi: I didn't recognized any date/time delays. The productive systems are currently not rebooted since a year. Time incorrectness would also concern other services (kerberos) and was not observed.