From: Lionel B. <lio...@bo...> - 2004-11-17 16:53:29
|
HaJo Schatz wrote the following on 17.11.2004 16:40 : >Lionel, > >Pls don't dig deep into the long sender name issue, it seems I have >screwed up while going through my maillogs. The "sender too long" is in >fact from the old version of sqlgrey. I have now identified that 1.3.0 >crashed differently: > > OK. >Nov 16 19:16:55 sun sqlgrey[18895]: Error: couldn't access domain_awl >table: FATAL: This connection has been terminated by the administrator. >Nov 16 19:16:57 sun sqlgrey[18895]: fatal: Can't connect to DB: could >not connect to server: Connection refused at /usr/bin/sqlgrey line 336. >Nov 16 19:16:58 sun sqlgrey[18895]: warning: Database handle destroyed >without explicit disconnect at /usr/bin/sqlgrey line 336. > >I'm not sure why the "administrator terminated the connection", but I'm >trying to trace this back. Is it unavoidable that sqlgrey terminates if >there's an error with the DB connection? > When disconnected SQLgrey tries to reconnect to the database but if it fails it will exit. 1.1.3 was more robust in this respect because it never retried immediately. But it had a bug which made it stop filtering for as much as 24hours before trying to reconnect to the database. I consider this a bug in 1.2.0 and 1.3.x, what I'll code is a more tolerant behaviour in 1.2.1 to fix the problem (never exit) and redesign 1.3 to sleep a little instead of trying to reconnect immediately (in order to allow a temporary connection problem to go away) and refuse to exit on DB errors too. > Maybe a setting in the config >file could determine if in such a case the mail is considered either >pass or fail > Fail could be nasty ! > and a warning being issued to syslog or postmaster. > syslog is already ready. Postmaster could be handy. > The >connection could then be re-tried on the next mail-RX, no? > >Sorry for the trouble, > > > Don't be sorry, this report is quite useful :-) Best regards, Lionel. |