sqlgrey-users — Users of SQLgrey

Re: [Sqlgrey-users] [RELEASE] 1.6.5

[David R. <dr...@gm...>]

On 7/26/05, Lionel Bouton <lio...@bo...> wrote:
> The bugfix for clean_method handling (thanks again Rupa), 1.6.5 is on
> sourceforge:

Thanks, I had a hang today with clean_method =3D sync and thought I must
have been going crazy.  Running now on 1.6.5 and will let you know if
it hangs again.

-Dave

Re: [Sqlgrey-users] Postgresql + lost connection

[Lionel B. <lio...@bo...>]

Daniel V. Pedersen wrote the following on 27.07.2005 18:28 :

>>-----Original Message-----
>>From: sql...@li... [mailto:sqlgrey-users-
>>ad...@li...] On Behalf Of Lionel Bouton
>>
>>You don't get only these messages, do you?
>>    
>>
>
>Well, apart from the regular log output, yup, that's pretty much
>All in the mail log I get from grey, that looks erroneous.
>
>I do get a mail almost directly after with a "SQLgrey recovered DB".
>
>  
>
>>Which SQLgrey version are you using? Can you reproduce the problem with
>>SQLgrey 1.6.5 and "clean_method=sync" in sqlgrey.conf?
>>    
>>
>
>1.6.4, And I don't know, I suspected something with the cleaning since
>That happens each 1800th second. I'll give 1.6.5 a swing tomorrow, see how
>It behaves. Oh, and yes, changed from async to sync, same problem.
>  
>

All versions before 1.6.5 didn't use sync when told to do so. Some 
configurations have database related problems with async...

Lionel

RE: [Sqlgrey-users] Postgresql + lost connection

[Daniel V. P. <dv...@cs...>]

> -----Original Message-----
> From: sql...@li... [mailto:sqlgrey-users-
> ad...@li...] On Behalf Of Lionel Bouton
> 
> You don't get only these messages, do you?

Well, apart from the regular log output, yup, that's pretty much
All in the mail log I get from grey, that looks erroneous.

I do get a mail almost directly after with a "SQLgrey recovered DB".

> Which SQLgrey version are you using? Can you reproduce the problem with
> SQLgrey 1.6.5 and "clean_method=sync" in sqlgrey.conf?

1.6.4, And I don't know, I suspected something with the cleaning since
That happens each 1800th second. I'll give 1.6.5 a swing tomorrow, see how
It behaves. Oh, and yes, changed from async to sync, same problem.

/Dan.

Re: [Sqlgrey-users] Postgresql + lost connection

[Lionel B. <lio...@bo...>]

Daniel V. Pedersen wrote the following on 27.07.2005 14:41 :

> Howdi, I recently installed Sqlgrey and it seems to work lovely, apart
>
> From I often get database disconnects/reconnects.
>
>  
>
> Mail goes:
>
> SQLgrey encountered an SQL error and triggered a reconnection to: 
> DBI:Pg:dbname=sqlgrey;host=<host>
>
> And the reconnect goes fine.
>
>  
>
> Log:
>
>  
>
> Jul 27 10:37:13 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 11:07:16 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 11:37:42 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 12:07:39 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 12:37:34 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 13:07:46 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>
> Jul 27 13:37:45 spamwall1 sqlgrey: dbaccess: error: couldn't get now() 
> from DB: no connection to the server
>

You don't get only these messages, do you?

Which SQLgrey version are you using? Can you reproduce the problem with 
SQLgrey 1.6.5 and "clean_method=sync" in sqlgrey.conf?

Lionel.

RE: [Sqlgrey-users] Postgresql + lost connection

[Daniel V. P. <dv...@cs...>]

Arf, Server is 8.0.1 / client side is 8.0.3

 

  _____  

From: sql...@li...
[mailto:sql...@li...] On Behalf Of Daniel V.
Pedersen
Sent: 27. juli 2005 14:41
To: sql...@li...
Subject: [Sqlgrey-users] Postgresql + lost connection

 

Howdi, I recently installed Sqlgrey and it seems to work lovely, apart

From I often get database disconnects/reconnects.

 

Mail goes:

SQLgrey encountered an SQL error and triggered a reconnection to:
DBI:Pg:dbname=sqlgrey;host=<host>

And the reconnect goes fine.

 

Log:

 

Jul 27 10:37:13 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 11:07:16 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 11:37:42 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 12:07:39 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 12:37:34 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 13:07:46 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 13:37:45 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

 

This seems to happen every half hour or so.

 

Perl is 5.8.5, OS FreeBSD 5.3, Postfix 2.2.5, PostgreSQL 8.0.x (Server 8.0.3
/ client libs 8.0.5), DBD::Pg 1.43, DBI 1.48

 

I've tried fiddling and searching but coulden't really find anything,

So sorry if this have been asked/answered in the past.

 

Cheers,

 

Dan.

[Sqlgrey-users] Postgresql + lost connection

[Daniel V. P. <dv...@cs...>]

Howdi, I recently installed Sqlgrey and it seems to work lovely, apart

From I often get database disconnects/reconnects.

 

Mail goes:

SQLgrey encountered an SQL error and triggered a reconnection to:
DBI:Pg:dbname=sqlgrey;host=<host>

And the reconnect goes fine.

 

Log:

 

Jul 27 10:37:13 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 11:07:16 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 11:37:42 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 12:07:39 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 12:37:34 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 13:07:46 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

Jul 27 13:37:45 spamwall1 sqlgrey: dbaccess: error: couldn't get now() from
DB: no connection to the server

 

This seems to happen every half hour or so.

 

Perl is 5.8.5, OS FreeBSD 5.3, Postfix 2.2.5, PostgreSQL 8.0.x (Server 8.0.3
/ client libs 8.0.5), DBD::Pg 1.43, DBI 1.48

 

I've tried fiddling and searching but coulden't really find anything,

So sorry if this have been asked/answered in the past.

 

Cheers,

 

Dan.

Re: [Sqlgrey-users] [RELEASE] 1.6.5

[Lionel B. <lio...@bo...>]

Ray Booysen wrote the following on 26.07.2005 22:15 :

> [...]
> Hi Lionel
>
> Can I use the 1.6.4 ebuild for 1.6.4 and just rename it?


Yes (note that the latest ebuild is always included in the tar.bz2). 
I'll update the website to point to a 1.6.5 ebuild.

Lionel

Re: [Sqlgrey-users] [RELEASE] 1.6.5

[Ray B. <rj_...@rj...>]

Lionel Bouton wrote:

> The bugfix for clean_method handling (thanks again Rupa), 1.6.5 is on 
> sourceforge:
>
> http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=344923 
>
>
> Lionel.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

Hi Lionel

Can I use the 1.6.4 ebuild for 1.6.4 and just rename it?

Regards
Ray

[Sqlgrey-users] [RELEASE] 1.6.5

[Lionel B. <lio...@bo...>]

The bugfix for clean_method handling (thanks again Rupa), 1.6.5 is on 
sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=344923

Lionel.

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Lionel B. <lio...@bo...>]

Rupa Schomaker (lists) wrote the following on 26.07.2005 18:27 :

>On 7/26/2005 4:27 AM, Lionel Bouton wrote:
>  
>
>>>Is it clean_method or cleanup_method?  I now have both in my
>>>sqlgrey.conf file set to sync.
>>>
>>>75: $dflt{clean_method}       = 'sync';
>>>and then
>>>1403:    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {
>>>      
>>>
>>Hum...
>>
>>Good catch. I'll patch the code to properly support "clean_method" as
>>specified in the example sqlgrey.conf. Putting "cleanup_method = sync"
>>in sqlgrey.conf should indeed avoid the fork in 1.6.4
>>    
>>
>
>It also looks like not all places use start_cleanup() and instead call
>fork_cleanup() instead.  Also, the initialization of the sqlgrey hash
>doesn't set cleanup_method which resulted in async being used no matter
>what.
>
>Patch attached.
>
>  
>

Good catch again :-)
This start/fork_cleanup mixup is odd, I remember having checked an 
intermediate version for such cases (I was initialy unsure on how to 
name these methods) and corrected them. I may have mixed up borked and 
cleaned version at some point before commiting...

I'll drop support for cleanup_method and only leave support for 
clean_method (TODO: make the config parser aware of supported options 
and complain when unknown are found). This was the only config entry 
advertised in the etc/sqlgrey.conf example.

Preparing a 1.6.5 version now.

Lionel

PS: your strace following the two processes might help understand what's 
going on when using tha async method, I'll try to give it a shot later.

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/26/2005 4:27 AM, Lionel Bouton wrote:
>> Is it clean_method or cleanup_method?  I now have both in my
>> sqlgrey.conf file set to sync.
>>
>> 75: $dflt{clean_method}       = 'sync';
>> and then
>> 1403:    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {
> 
> Hum...
> 
> Good catch. I'll patch the code to properly support "clean_method" as
> specified in the example sqlgrey.conf. Putting "cleanup_method = sync"
> in sqlgrey.conf should indeed avoid the fork in 1.6.4

It also looks like not all places use start_cleanup() and instead call
fork_cleanup() instead.  Also, the initialization of the sqlgrey hash
doesn't set cleanup_method which resulted in async being used no matter
what.

Patch attached.

-- 
 -Rupa

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Lionel B. <lio...@bo...>]

Rupa Schomaker (lists) wrote the following on 26.07.2005 12:15 :

>On 7/26/2005 2:04 AM, Rupa Schomaker (lists) wrote:
>  
>
>>clean_method = sync # sync : cleanup is done in the main process,
>>    
>>
>
>Is it clean_method or cleanup_method?  I now have both in my
>sqlgrey.conf file set to sync.
>
>75: $dflt{clean_method}       = 'sync';
>and then
>1403:    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {
>
>  
>

Hum...

Good catch. I'll patch the code to properly support "clean_method" as 
specified in the example sqlgrey.conf. Putting "cleanup_method = sync" 
in sqlgrey.conf should indeed avoid the fork in 1.6.4

Lionel

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/26/2005 2:04 AM, Rupa Schomaker (lists) wrote:
> clean_method = sync # sync : cleanup is done in the main process,

Is it clean_method or cleanup_method?  I now have both in my
sqlgrey.conf file set to sync.

75: $dflt{clean_method}       = 'sync';
and then
1403:    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {

-- 
 -Rupa

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/25/2005 10:49 PM, Rupa Schomaker (lists) wrote:
> Ok, the strace:
> 
> # strace -p 6538
> Process 6538 attached - interrupt to quit
> poll(
> 
> Doesn't say what fd it is polling on. :(

Config file:

# grep '^[^# ]' /etc/sqlgrey/sqlgrey.conf
user = sqlgrey
pidfile = /var/run/sqlgrey.pid
reconnect_delay = 5
max_connect_age = 24
awl_age = 33
group_domain_level = 5 # wait for 10 validated adresses to add a whole
                          # domain in AWL
db_type = Pg
db_name = system
db_host = localhost
db_user = sqlgrey
db_pass = aPasswordOrSomething
clean_method = sync # sync : cleanup is done in the main process,
prepend = 1
whitelists_host = sqlgrey.bouton.name
admin_mail = pos...@ru...

More complete strace (still don't understand why there is a fork()):

[snip]
read(9, "request=smtpd_access_policy\nprot"..., 8192) = 386
stat64("/etc/sqlgrey/clients_ip_whitelist.local", {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
stat64("/etc/sqlgrey/clients_fqdn_whitelist.local",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
send(7, "Q\0\0\0\21SELECT now()\0", 18, 0) = 18
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(7, "T\0\0\0\34\0\1now\0\0\0\0\0\0\0\0\0\4\240\0\10\377\377"...,
16384, 0) = 87
time(NULL)                              = 1122364510
clone(Process 14908 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7d2b648) = 14908
[pid 10976] time( <unfinished ...>
[pid 14908] getpid( <unfinished ...>
[pid 10976] <... time resumed> NULL)    = 1122364510
[pid 14908] <... getpid resumed> )      = 14908
[pid 14908] getppid( <unfinished ...>
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE],  <unfinished ...>
[pid 14908] <... getppid resumed> )     = 10976
[pid 10976] <... rt_sigprocmask resumed> [], 8) = 0
[pid 10976] send(7, "P\0\0\0\235dbdpg_284\0SELECT 1 FROM dom"..., 163,
0) = 163
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "1\0\0\0\4Z\0\0\0\5I", 16384, 0) = 11
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7,
"B\0\0\0008\0dbdpg_284\0\0\0\0\2\0\0\0\fwillinet"..., 79, 0) = 79
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7,
"2\0\0\0\4T\0\0\0!\0\1?column?\0\0\0\0\0\0\0\0\0\0\27\0"..., 16384, 0) = 57
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_284\0", 26, 0) = 26
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "C\0\0\0\17DEALLOCATE\0Z\0\0\0\5I", 16384, 0) = 22
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "P\0\0\0\260dbdpg_285\0SELECT 1 FROM fro"..., 182,
0) = 182
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "1\0\0\0\4Z\0\0\0\5I", 16384, 0) = 11
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "B\0\0\0H\0dbdpg_285\0\0\0\0\3\0\0\0\frlrugt15"...,
95, 0) = 95
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll( <unfinished ...>
[pid 14908] open("/etc/hosts", O_RDONLY) = 10
[pid 14908] fcntl64(10, F_GETFD)        = 0
[pid 14908] fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
[pid 14908] fstat64(10, {st_mode=S_IFREG|0666, st_size=305, ...}) = 0
[pid 14908] mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000
[pid 14908] read(10, "127.0.0.1\tlocalhost\n192.168.1.20"..., 4096) = 305
[pid 14908] read(10, "", 4096)          = 0
[pid 14908] close(10)                   = 0
[pid 14908] munmap(0xb7fe8000, 4096)    = 0
[pid 14908] open("/etc/hosts", O_RDONLY) = 10
[pid 14908] fcntl64(10, F_GETFD)        = 0
[pid 14908] fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
[pid 14908] fstat64(10, {st_mode=S_IFREG|0666, st_size=305, ...}) = 0
[pid 14908] mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000
[pid 14908] read(10, "127.0.0.1\tlocalhost\n192.168.1.20"..., 4096) = 305
[pid 14908] read(10, "", 4096)          = 0
[pid 14908] close(10)                   = 0
[pid 14908] munmap(0xb7fe8000, 4096)    = 0
[pid 14908] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 10
[pid 14908] setsockopt(10, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 14908] fcntl64(10, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
[pid 14908] fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
[pid 14908] connect(10, {sa_family=AF_INET, sin_port=htons(5432),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in
progress)
[pid 14908] poll([{fd=10, events=POLLOUT|POLLERR, revents=POLLOUT}], 1,
-1) = 1
[pid 14908] getsockopt(10, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
[pid 14908] getsockname(10, {sa_family=AF_INET, sin_port=htons(46276),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
[pid 14908] poll([{fd=10, events=POLLOUT|POLLERR, revents=POLLOUT}], 1,
-1) = 1
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "\0\0\0\10\4\322\26/", 8, 0) = 8
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10, "N", 16384, 0)     = 1
[pid 14908] poll([{fd=10, events=POLLOUT|POLLERR, revents=POLLOUT}], 1,
-1) = 1
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "\0\0\0&\0\3\0\0user\0sqlgrey\0database\0sy"...,
38, 0) = 38
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10,
"R\0\0\0\10\0\0\0\0S\0\0\0\36client_encoding\0SQ"..., 16384, 0) = 245
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(7, "Q\0\0\0\27DEALLOCATE dbdpg_1\0", 24, 0) = 24
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll( <unfinished ...>
[pid 10976] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7,
"2\0\0\0\4T\0\0\0!\0\1?column?\0\0\0\0\0\0\0\0\0\0\27\0"..., 16384, 0) = 162
[pid 10976] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 10976] write(5, "<20>sqlgrey: warning: ERROR:  pr"..., 75) = 75
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_285\0", 26, 0) = 26
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "Z\0\0\0\5IC\0\0\0\17DEALLOCATE\0Z\0\0\0\5I", 16384,
0) = 28
[pid 10976] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 10976] write(5, "<20>sqlgrey: warning: message ty"..., 72) = 72
[pid 10976] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 10976] write(5, "<20>sqlgrey: warning: message ty"..., 72) = 72
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "P\0\0\0\301dbdpg_286\0SELECT 1 FROM con"..., 199,
0) = 199
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "1\0\0\0\4Z\0\0\0\5I", 16384, 0) = 11
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "B\0\0\0Z\0dbdpg_286\0\0\0\0\4\0\0\0\frlrugt15"...,
113, 0) = 113
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7,
"2\0\0\0\4T\0\0\0!\0\1?column?\0\0\0\0\0\0\0\0\0\0\27\0"..., 16384, 0) = 57
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_286\0", 26, 0) = 26
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "C\0\0\0\17DEALLOCATE\0Z\0\0\0\5I", 16384, 0) = 22
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "P\0\0\1\tdbdpg_287\0SELECT 1 FROM con"..., 271, 0)
= 271
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "1\0\0\0\4Z\0\0\0\5I", 16384, 0) = 11
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "B\0\0\0Z\0dbdpg_287\0\0\0\0\4\0\0\0\frlrugt15"...,
113, 0) = 113
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7,
"2\0\0\0\4T\0\0\0!\0\1?column?\0\0\0\0\0\0\0\0\0\0\27\0"..., 16384, 0) = 57
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_287\0", 26, 0) = 26
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "C\0\0\0\17DEALLOCATE\0Z\0\0\0\5I", 16384, 0) = 22
[pid 10976] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 10976] write(5, "<21>sqlgrey: grey: new: 68.59.13"..., 99) = 99
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\232INSERT INTO connect (sender"..., 155, 0)
= 155
[pid 10976] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 10976] poll([{fd=7, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
[pid 10976] recv(7, "C\0\0\0\25INSERT 2240503 1\0Z\0\0\0\5I", 16384, 0) = 28
[pid 10976] select(16, [6 8 9], [9], NULL, NULL) = 1 (out [9])
[pid 10976] write(9, "action=defer_if_permit Greyliste"..., 49) = 49
[pid 10976] select(16, [6 8 9], [], NULL, NULL) = 1 (in [9])
[pid 10976] read(9, "request=smtpd_access_policy\nprot"..., 8192) = 386
[pid 10976] stat64("/etc/sqlgrey/clients_ip_whitelist.local",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 10976] stat64("/etc/sqlgrey/clients_fqdn_whitelist.local",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\21SELECT now()\0", 18, 0) = 18
[pid 14908] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 10976] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid 14908] recv(7,  <unfinished ...>
[pid 10976] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 14908] <... recv resumed>
"T\0\0\0\34\0\1now\0\0\0\0\0\0\0\0\0\4\240\0\10\377\377"..., 16384, 0) = 87
[pid 10976] poll( <unfinished ...>
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_185\0", 26, 0) = 26
[pid 10976] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 14908] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid 10976] recv(7,  <unfinished ...>
[pid 14908] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 10976] <... recv resumed> "E\0\0\0jSERROR\0C26000\0Mprepared
sta"..., 16384, 0) = 113
[pid 14908] poll( <unfinished ...>
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\27DEALLOCATE dbdpg_1\0", 24, 0) = 24
[pid 14908] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 10976] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid 14908] recv(7,  <unfinished ...>
[pid 10976] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 14908] <... recv resumed> "E\0\0\0hSERROR\0C26000\0Mprepared
sta"..., 16384, 0) = 111
[pid 10976] poll( <unfinished ...>
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_184\0", 26, 0) = 26
[pid 10976] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 14908] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid 10976] recv(7,  <unfinished ...>
[pid 14908] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 10976] <... recv resumed> "E\0\0\0jSERROR\0C26000\0Mprepared
sta"..., 16384, 0) = 113
[pid 14908] poll( <unfinished ...>
[pid 10976] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 10976] send(7, "Q\0\0\0\31DEALLOCATE dbdpg_185\0", 26, 0) = 26
[pid 14908] <... poll resumed> [{fd=7, events=POLLIN|POLLERR,
revents=POLLIN}], 1, -1) = 1
[pid 10976] rt_sigprocmask(SIG_SETMASK, [],  <unfinished ...>
[pid 14908] recv(7,  <unfinished ...>
[pid 10976] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 14908] <... recv resumed> "E\0\0\0jSERROR\0C26000\0Mprepared
sta"..., 16384, 0) = 113
[pid 10976] poll( <unfinished ...>
[pid 14908] time(NULL)                  = 1122364519
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "Q\0\0\0iDELETE FROM from_awl WHERE "..., 106, 0) = 106
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10, "C\0\0\0\rDELETE 0\0Z\0\0\0\5I", 16384, 0) = 20
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "Q\0\0\0kDELETE FROM domain_awl WHER"..., 108, 0) = 108
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10, "C\0\0\0\rDELETE 0\0Z\0\0\0\5I", 16384, 0) = 20
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "Q\0\0\0\234SELECT sender_name, sender_"..., 157,
0) = 157
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10,
"T\0\0\0\216\0\5sender_name\0\0\"\22\373\0\1\0\0\4\23\377"..., 16384, 0)
= 2199
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 63.205.10.228"..., 105) = 105
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 102) = 102
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 102) = 102
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 100) = 100
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 101) = 101
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 101) = 101
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 209.51.220.15"..., 130) = 130
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 106) = 106
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 24.27.75.158:"..., 101) = 101
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 64.192.204.19"..., 110) = 110
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 211.216.196.7"..., 103) = 103
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 61.16.208.201"..., 109) = 109
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 218.71.72.1: "..., 109) = 109
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 218.253.4.136"..., 99) = 99
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 220.191.88.71"..., 99) = 99
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 212.35.220.11"..., 98) = 98
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 209.51.220.14"..., 130) = 130
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 222.65.105.11"..., 107) = 107
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 62.68.174.135"..., 110) = 110
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: spam: 82.240.137.57"..., 116) = 116
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "Q\0\0\0jDELETE FROM connect WHERE f"..., 107, 0) = 107
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] poll([{fd=10, events=POLLIN|POLLERR, revents=POLLIN}], 1,
-1) = 1
[pid 14908] recv(10, "C\0\0\0\16DELETE 20\0Z\0\0\0\5I", 16384, 0) = 21
[pid 14908] time(NULL)                  = 1122364519
[pid 14908] select(8, [5], NULL, [5], {0, 0}) = 0 (Timeout)
[pid 14908] write(5, "<21>sqlgrey: perf: spent 0s clea"..., 80) = 80
[pid 14908] rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
[pid 14908] send(10, "X\0\0\0\4", 5, 0) = 5
[pid 14908] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 14908] close(10)                   = 0
[pid 14908] close(9)                    = 0
[pid 14908] close(6)                    = 0
[pid 14908] stat64("/usr/lib/perl5/auto/DBI/DESTROY.al", 0x804c0c8) = -1
ENOENT (No such file or directory)
[pid 14908] open("/etc/perl/auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE)
= -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/local/lib/perl/5.8.7/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/local/share/perl/5.8.7/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/lib/perl5/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/share/perl5/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/lib/perl/5.8/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/share/perl/5.8/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/local/lib/site_perl/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/local/lib/perl/5.8.1/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("/usr/local/share/perl/5.8.1/auto/DBI/DESTROY.al",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 14908] open("./auto/DBI/DESTROY.al", O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
[pid 14908] close(3)                    = 0
[pid 14908] close(8)                    = 0
[pid 14908] close(5)                    = 0
[pid 14908] exit_group(0)               = ?
Process 14908 detached
<... poll resumed> [{fd=7, events=POLLIN|POLLERR}], 1, -1) = -1 EINTR
(Interrupted system call)
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
poll(


-- 
 -Rupa

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/25/2005 12:19 PM, Lionel Bouton wrote:
> You are the first one to report this bug with "clean_method = sync".
> This is *odd*. I need to be absolutely sure about that: please make sure
> that there's no older sqlgrey version lying around (only 1.6.4 uses the
> clean_method entry correctly).

bummer. :(  Just did a diff against the expanded 1.6.4 tar and it is the
same.

> 
> If this is the case then there probably is a bug in the DBI/DBD layer
> according to the following line you sent in your other mail:
> 
> Jul 25 10:18:43 shakti sqlgrey: dbaccess: error: couldn't get reconnect
> delay: ERROR:  prepared statement "dbdpg_282" does not exist

This isn't consistent with a freeze though.  Just noticed it while
searching through the logs.

> Next time you get a freeze, could you
> 1/ strace the process to see what it is blocking on?

# ps -ef | grep sqlgrey
sqlgrey   6538     1  0 20:52 ?        00:00:00 /usr/bin/perl -w
/var/lib/sqlgrey/sqlgrey -d
postgres  9246  5306  0 21:52 ?        00:00:00 postgres: sqlgrey system
127.0.0.1(57579) idle



sqlgrey  10783  6538  0 22:37 ?        00:00:00 [sqlgrey] <defunct>

1 parent process, one (defunct) child process (eh?  how can that be with
clean_method = sync ?).  One connection to the db.

Ok, the strace:

# strace -p 6538
Process 6538 attached - interrupt to quit
poll(

Doesn't say what fd it is polling on. :(

> 2/ At the same time I'm wondering if DBI is leaking connections, could
> you check the number of open connections on PostgreSQL when a freeze
> occur? You can either do a 'ps aux' on the database server to check how
> many connections there are on the sqlgrey database or connect as the
> 'postgres' user on whatever table and execute (I'm not sure if every
> config supports this):
> SELECT * from pg_stat_activity WHERE datname = 'sqlgrey';

Just one connection (see above).

> 
> Lionel.

-- 
 -Rupa

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Lionel B. <lio...@bo...>]

Rupa Schomaker (lists) wrote the following on 25.07.2005 19:26 :

>On 7/5/2005 5:05 AM, Lionel Bouton wrote:
>  
>
>>Ok,
>>
>>we must find out what triggers these freezes. As I couldn't reproduce
>>them on my systems, I'd like to have some feedback from all 1.6/1.7 users.
>>    
>>
>
>I just started experiencing this problem.  Small volume mail server
>(3-6k msgs a day).  I have to restart sqlgrey a few times a day.
>
> > Could you please fill in the following:
>  
>
>>Do you have freeze problems: (yes/no)
>>    
>>
>
>yes
>
>  
>
>>Latest SQLgrey version used: (1.6.[012] / 1.7.0)
>>    
>>
>
>1.6.4 from sf.net with clean_method = sync.
>  
>

You are the first one to report this bug with "clean_method = sync". 
This is *odd*. I need to be absolutely sure about that: please make sure 
that there's no older sqlgrey version lying around (only 1.6.4 uses the 
clean_method entry correctly).

If this is the case then there probably is a bug in the DBI/DBD layer 
according to the following line you sent in your other mail:

Jul 25 10:18:43 shakti sqlgrey: dbaccess: error: couldn't get reconnect delay: ERROR:  prepared statement "dbdpg_282" does not exist


The code takes great length to make sure the prepared statement indeed 
exists before calling execute (SQLgrey tests if prepare_cached returns a 
defined value before attempting to call execute on it). My guess is that 
there's a bug in DBI that makes it lose the prepared statement just 
after preparing it or checking it is already in its cache.

This is already surprising, but the freeze in itself is even more 
surprising. From the various logs related to this problem it seems 
SQLgrey is blocked trying to reconnect to the database.

Next time you get a freeze, could you
1/ strace the process to see what it is blocking on?
2/ At the same time I'm wondering if DBI is leaking connections, could 
you check the number of open connections on PostgreSQL when a freeze 
occur? You can either do a 'ps aux' on the database server to check how 
many connections there are on the sqlgrey database or connect as the 
'postgres' user on whatever table and execute (I'm not sure if every 
config supports this):
SELECT * from pg_stat_activity WHERE datname = 'sqlgrey';

Lionel.

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/25/2005 10:26 AM, Rupa Schomaker (lists) wrote:
> I just started experiencing this problem.  Small volume mail server
> (3-6k msgs a day).  I have to restart sqlgrey a few times a day.

I also noticed the following in my mail.log (uninitialized vars):

Jul 25 09:15:50 shakti sqlgrey: Process Backgrounded
Jul 25 09:15:50 shakti sqlgrey: 2005/07/25-09:15:50 sqlgrey (type
Net::Server::Multiplex) starting! pid(15110)
Jul 25 09:15:50 shakti sqlgrey: Binding to TCP port 2501 on host localhost
Jul 25 09:15:50 shakti sqlgrey: Setting gid to "1016 1016"
Jul 25 09:15:50 shakti sqlgrey: Setting uid to "1016"
[...]
Jul 25 10:18:43 shakti sqlgrey: dbaccess: error: couldn't get reconnect
delay: ERROR:  prepared statement "dbdpg_282" does not exist
Jul 25 10:18:43 shakti sqlgrey: warning: Use of uninitialized value in
concatenation (.) or string at /var/lib/sqlgrey/sqlgrey line 2002.
Jul 25 10:18:43 shakti sqlgrey: grey: reconnect ok: 64.4.31(64.4.31.16),
[removed] -> [removed]
[snip]
Jul 25 10:18:43 shakti sqlgrey: warning: Use of uninitialized value in
concatenation (.) or string at /var/lib/sqlgrey/sqlgrey line 227.
Jul 25 10:18:43 shakti sqlgrey: dbaccess: warning: couldn't do query:
INSERT INTO from_awl (sender_name, sender_domain, src, first_seen,
last_seen) VALUES('[removed]','hotmail.com','64.4.31','sql
error',NOW()): , reconnecting to DB
Jul 25 10:18:43 shakti postfix/qmgr[16103]: 7C2999423E3:
from=<sq...@ru...>, size=423, nrcpt=1 (queue active)
Jul 25 10:18:43 shakti postfix/pickup[17307]: 83C949423E4: uid=1016
from=<sqlgrey>
Jul 25 10:18:43 shakti postfix/cleanup[17386]: 83C949423E4:
message-id=<200...@ma...>
Jul 25 10:18:43 shakti sqlgrey: warning: Use of uninitialized value in
concatenation (.) or string at /var/lib/sqlgrey/sqlgrey line 2025.


-- 
 -Rupa

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Rupa S. (lists) <rup...@ru...>]

On 7/5/2005 5:05 AM, Lionel Bouton wrote:
> Ok,
> 
> we must find out what triggers these freezes. As I couldn't reproduce
> them on my systems, I'd like to have some feedback from all 1.6/1.7 users.

I just started experiencing this problem.  Small volume mail server
(3-6k msgs a day).  I have to restart sqlgrey a few times a day.

 > Could you please fill in the following:
> 
> Do you have freeze problems: (yes/no)

yes

> Latest SQLgrey version used: (1.6.[012] / 1.7.0)

1.6.4 from sf.net with clean_method = sync.

> OS/Distribution: (uname -a)

Linux shakti 2.6.11-1-k7 #1 Mon Jun 20 21:26:23 MDT 2005 i686 GNU/Linux

Debian unstable (sid) -- up to date.

> Perl version: (see perl -v)

v5.8.7

> Net-Server-Multiplex version: (perl -MNet::Server::Multiplex -e 'print
> $Net::Server::Multiplex::VERSION')

0.87

> How many mails/day:

3-6k a day.

-- 
 -Rupa

Re: [Sqlgrey-users] Dealing with pooled outgoing servers

[Lionel B. <lio...@bo...>]

Jeff Rice wrote the following on 22.07.2005 20:06 :

>Looking at my log today, I noticed a particular server (or set of
>servers, actually) that kept connecting to retry a single message.  The
>sender email, recipient email, and helo were the same but the sending
>servers were different (but on the same C net).  I believe that other
>ISPs use a similar technique -- AOL, for example?
>
>Can we think about a strategy to address this, without whitelisting
>these blocks?   If the C subnet is going to get whitelisted (assuming it
> has a reverse addy and is not dynamic) once it retries, is there a
>fundamental reason why the C net can't be used in the connect db rather
>than a full quad?
>
>  
>

 From sqlgrey.conf :

## Greylisting method:
# - full   : greylist by IP address
# - classc : greylist by class C network. eg:
#            2.3.4.6 connection accepted if 2.3.4.145 did connect earlier
# - smart  : greylist by class C network unless there is no reverse lookup
#            or it looks like a home-user address
# Default is smart
# greymethod = smart

If you use "full" the behaviour you witnessed is expected. If you use 
"smart" most of the time SQLgrey will find out that it's better to use 
the class C network when it is a real SMTP server from a pool but will 
occasionnaly fail to guess that class C is more suited so you can expect 
what you saw sometimes. If you use "classc" it will always use the class 
C network.

Note: "smart" relies on the fqdn Postfix hands over for the IP address, 
if the DNS is misconfigured on the other end of the communication, smart 
can't find out if the IP is more likely to be a SMTP server or a Windows 
zombie on a home connection. To be on the safe side it will use the 
whole IP.

I'm interested in the actual IP addresses you have problem with. 
Depending on the actual DNS entries I could modify the tests so that 
"smart" is more ... smart.

Lionel.

[Sqlgrey-users] Dealing with pooled outgoing servers

[Jeff R. <py...@fi...>]

Looking at my log today, I noticed a particular server (or set of
servers, actually) that kept connecting to retry a single message.  The
sender email, recipient email, and helo were the same but the sending
servers were different (but on the same C net).  I believe that other
ISPs use a similar technique -- AOL, for example?

Can we think about a strategy to address this, without whitelisting
these blocks?   If the C subnet is going to get whitelisted (assuming it
 has a reverse addy and is not dynamic) once it retries, is there a
fundamental reason why the C net can't be used in the connect db rather
than a full quad?

Jeff

Re: [Sqlgrey-users] 1.6.x and 1.7.x freezes

[Ed S. (s. list) <sq...@cr...>]

Here's an update since a few things have changed on my server. It may be
too soon to see if that wondrous lockup bug has been resolved, but it
seems that it *MAY* have indeed been squashed.

Previously, as you know all too well, it would fail/lock-up within a
day's time.  Until the power outage, it was working flawlessly since the
upgrade to 1.6.4.

So, below is an updated "checklist" for your perusal.



Ed Shornock (sqlgrey list) wrote:
> Lionel Bouton wrote:

>>Do you have freeze problems: (yes/no)
> 
> yes  :(

The answer is now "maybe"

With Sqlgrey 1.6.4 (installed on July 8th) and the following settings:
---start---
$ grep -v '#' /etc/sqlgrey/sqlgrey.conf  |strings
conf_dir = /etc/sqlgrey
loglevel = 4
user = sqlgrey
group = nogroup
db_type = Pg
db_name = sqlgrey
db_host = localhost
db_user = sqlgrey
db_pass = ANotSoCommonPassword
admin_mail = pos...@cr...
---end---

Sqlgrey was working *perfectly*.  Was, in the past tense, because a
f%#$#@ing brown-out made my "server" lose power. :(

So Sqlgrey stopped working through no fault of its own. :P


>>Latest SQLgrey version used: (1.6.[012] / 1.7.0)
1.6.4

>>OS/Distribution: (uname -a)
> 
Debian Sid (unstable)
$ uname -a
Linux darkside 2.6.12.2-p4 #1 Thu Jul 7 23:50:52 EDT 2005 i686 GNU/Linux

>>Perl version: (see perl -v)
$ perl -v

This is perl, v5.8.7 built for i386-linux-thread-multi




Note:  Recently, Perl packages were updated in Debian unstable with the
following ChangeLog:

perl (5.8.7-4) unstable; urgency=low

  * Don't generate broken md5sums for libperl5.8 (closes: #304640).
  * Build with gcc 4.0; restore standard (-O2) optimisation on arm, ia64
    and powerpc.  Remove gcc-2.95 build work-around for m68k.
  * Fix test of reenterant function return values which was causing
    perl to malloc itself to death if ERANGE was encountered before
    ENOENT (such as a long line in /etc/group; closes: #227621).

 -- Brendan O'Dea <bo...@de...>  Sat,  9 Jul 2005 11:14:13 +1000


About the time that it started locking up, the Perl ChangeLog showed:
perl (5.8.7-2) unstable; urgency=low

  * Sarge has released.  Rebuild for unstable.

 -- Brendan O'Dea <bo...@de...>  Tue,  7 Jun 2005 09:31:16 +1000



Is it related as a possible cause?  I have no idea.

>>Net-Server-Multiplex version: (perl -MNet::Server::Multiplex -e 'print
>>$Net::Server::Multiplex::VERSION')

> $ perl -MNet::Server::Multiplex -e 'print $Net::Server::Multiplex::VERSION'
> 0.88

>>How many mails/day:
Currently about 900/day

[Sqlgrey-users] [RELEASE] 1.6.4

[Lionel B. <lio...@bo...>]

Lionel Bouton wrote the following on 08.07.2005 21:23 :

>David Rees wrote the following on 08.07.2005 19:00 :
>
>  
>
>>On 7/7/05, Lionel Bouton <lio...@bo...> wrote:
>> 
>>
>>    
>>
>>>as the freeze problems with the new cleanup code aren't yet solved,
>>>1.6.3 is out with user configurable cleanups. By default the old method
>>>(synchronous cleanups delaying mail processing) is used:
>>>clean_method = sync
>>>if you want the new (sometime buggy):
>>>clean_method = async
>>>   
>>>
>>>      
>>>
>>1.6.3 still gets stuck for me with a child zombie when running with
>>clean_method = sync.
>>
>>Not sure why?  Trying async now.
>>
>> 
>>
>>    
>>
>
>Argh! Apparently this odd bug is driving me nuts :(
>
>Please change the line that reads:
>    if ($self->{sqlgrey}{cleanup_method} == 'sync') {
>into
>    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {
>
>That will be a 1.6.4 release...
>
>  
>

Here it is:
http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=340694

Lionel

Re: [Sqlgrey-users] Freezes, follow-up

[Edward J S. <ed...@cr...>]

Ed Shornock (sqlgrey list) wrote:

>Another hang with the patched 1.6.2 and a downloaded PostgreSQL.  
>

GRRRR


s/downloaded/downgraded/

Re: [Sqlgrey-users] [RELEASE] 1.6.3

[Lionel B. <lio...@bo...>]

David Rees wrote the following on 08.07.2005 19:00 :

>On 7/7/05, Lionel Bouton <lio...@bo...> wrote:
>  
>
>>as the freeze problems with the new cleanup code aren't yet solved,
>>1.6.3 is out with user configurable cleanups. By default the old method
>>(synchronous cleanups delaying mail processing) is used:
>>clean_method = sync
>>if you want the new (sometime buggy):
>>clean_method = async
>>    
>>
>
>1.6.3 still gets stuck for me with a child zombie when running with
>clean_method = sync.
>
>Not sure why?  Trying async now.
>
>  
>

Argh! Apparently this odd bug is driving me nuts :(

Please change the line that reads:
    if ($self->{sqlgrey}{cleanup_method} == 'sync') {
into
    if ($self->{sqlgrey}{cleanup_method} eq 'sync') {

That will be a 1.6.4 release...

Lionel.

Re: [Sqlgrey-users] Freezes, follow-up

[Lionel B. <lio...@bo...>]

Ed Shornock (sqlgrey list) wrote the following on 08.07.2005 20:56 :

>Ed Shornock (sqlgrey list) wrote:
>[snip]
>
>  
>
>>I did notice that on June 12 (by checking logs) that PGSQL was updated. 
>>
>>    
>>
>[snip]
>  
>
>>Let's see WTF the downgrading of the package does.  I'll post another
>>update if this fixes the problem (and I guess we'll figure out where to
>>go from there).
>>
>>    
>>
>
>Another hang with the patched 1.6.2 and a downloaded PostgreSQL.  No
>idea WTF is causing it (and why it's just Mr. Rees and myself having
>this problem).
>  
>

I'm still not sure myself. After a fork one needs to take precautions
with various things (file descriptors, sockets and so on...). The
current problem with SQLgrey is the amount of code in the
Net::Server::Multiplex module I'm not familiar with.
I already considered ditching it and replacing it with my own code
because there seems to be bugs in it (SIGHUP handling for example
doesn't work as documented and was pretty unusable when I tried to use
it). 1.6.3 'sync' clean_method should hopefully solve the problem for
the short time and I'll probably recode the socket handling in 1.7.x.

Lionel.