sqlgrey-users — Users of SQLgrey

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

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

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 wonder if it'd help to completely overwrite my config file and re-edit
it to compensate for the new options....hmm...let's do that with 1.6.3....

Re: [Sqlgrey-users] [RELEASE] 1.6.3

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

On 7/7/05, Lionel Bouton <lio...@bo...> wrote:
>=20
> 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 =3D sync
> if you want the new (sometime buggy):
> clean_method =3D async

1.6.3 still gets stuck for me with a child zombie when running with
clean_method =3D sync.

Not sure why?  Trying async now.

-Dave

Re: [Sqlgrey-users] 1.6.3

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

Lionel Bouton wrote:

>Ray Booysen wrote the following on 08.07.2005 16:04 :
>
>  
>
>>Hi
>>
>>I am getting the following error when starting SQLGrey
>>
>>Can't call method "do" on an undefined value at /usr/sbin/sqlgrey line
>>298.
>>
>>Any ideas?
>>
>>    
>>
>
>SQLgrey couldn't connect to the database on startup. Does it happen each
>time even if the database is started for some time (on some setups
>PostgreSQL startup scripts don't wait for the database to be up before
>exiting which could explain this behaviour)?
>
>Lionel.
>
>  
>
Couldn't connect is probably incorrect.  It came up when access was 
denied.  I upgraded to 1.6.3 and overwrote my config file so now login 
details were available. 

Apologies for the badly written email.

Regards
Ray

Re: [Sqlgrey-users] 1.6.3

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

Ray Booysen wrote the following on 08.07.2005 16:04 :

> Hi
>
> I am getting the following error when starting SQLGrey
>
> Can't call method "do" on an undefined value at /usr/sbin/sqlgrey line
> 298.
>
> Any ideas?
>

SQLgrey couldn't connect to the database on startup. Does it happen each
time even if the database is started for some time (on some setups
PostgreSQL startup scripts don't wait for the database to be up before
exiting which could explain this behaviour)?

Lionel.

Re: [Sqlgrey-users] 1.6.3

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

Ray Booysen wrote:

> Hi
>
> I am getting the following error when starting SQLGrey
>
> Can't call method "do" on an undefined value at /usr/sbin/sqlgrey line 
> 298.
>
> Any ideas?
>
> Regards
> Ray
>
Ignore please.  MySQL wasn't responding. 

Thanks
Ray

[Sqlgrey-users] 1.6.3

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

Hi

I am getting the following error when starting SQLGrey

Can't call method "do" on an undefined value at /usr/sbin/sqlgrey line 298.

Any ideas?

Regards
Ray

[Sqlgrey-users] [RELEASE] 1.6.3

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

Hi,

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 can be found here:
http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=340368

Note: sourceforge seems awfully slow at this time. Alternatively the
tar.bz2 archive can be found here too:
http://sqlgrey.bouton.name/sqlgrey-1.6.3.tar.bz2

Lionel.

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

[Brett H. <ha...@gm...>]

Hi

Do you have freeze problems: NO
Latest SQLgrey version used: 1.7.0
OS/Distribution: Suse 9.3 Kernel 2.6.8-24-smp #1 SMP i686 i686 i386 GNU/Lin=
ux
Perl version: v5.8.5 built for i586-linux-thread-multi
Net-Server-Multiplex version: 0.87=20
How many mails/day: 20 000

Regards
Brett


On 7/5/05, Lionel Bouton <lio...@bo...> wrote:
> Ok,
>=20
> 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=
.
>=20
> Could you please fill in the following:
>=20
> Do you have freeze problems: (yes/no)
> Latest SQLgrey version used: (1.6.[012] / 1.7.0)
> OS/Distribution: (uname -a)
> Perl version: (see perl -v)
> Net-Server-Multiplex version: (perl -MNet::Server::Multiplex -e 'print
> $Net::Server::Multiplex::VERSION')
> How many mails/day:
>=20
> I hope this will bring some pattern.
>=20
> Lionel.
>=20
>=20
> -------------------------------------------------------
> 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=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>=20
> !DSPAM:42ca7869265838998010312!
>=20
>

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

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

On 7/5/05, David Rees <dr...@gm...> wrote:
> Do you have freeze problems: not any more
> Latest SQLgrey version used: 1.6.2
> OS/Distribution: Fedora Core 4
> Perl version: 5.8.6
> Net-Server-Multiplex version: 0.88
> How many mails/day: 50-100
>=20
> Stopped hanging after I upgraded to perl-Net-Server 0.88 from 0.87 and
> turned up logging to 4.  Was OK with 1.6.1 although I am running 1.6.2
> with the no-hang patch you posted now.

Update: Just got a hang with a child stuck in zombie state here with
the above configuration.  Logging was set to normal this time.

-Dave

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

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

Ed Shornock (sqlgrey list) wrote:

>Lionel Bouton wrote:
>  
>
>>I'm interested by the result of the attached patch on configurations
>>where freezes occur...
>>    
>>
>I've reverted back to a pristine 1.6.2, applied this patch, turned the
>log level up to 4, and i'm strace'ing the sqlgrey process to a log file.
>
>I'll keep you posted...
>  
>
At around 12:40 AM, I noticed that SQLgrey locked up.  I was running
strace on the process at the time, this is the output of the strace
command.  SQLgrey unlocked after I restarted PGSQL:
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn()                             = ? (mask now [RTMIN])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 24973
waitpid(-1, 0xbff828f8, WNOHANG)        = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD RTMIN], 8) = 0
rt_sigaction(SIGCHLD, {0xb7eed7a0, [], 0}, {0xb7eed7a0, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
waitpid(24975, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 24975
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn()                             = ? (mask now [RTMIN])
rt_sigaction(SIGINT, {0xb7eed7a0, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0xb7eed7a0, [], 0}, NULL, 8) = 0
read(6, "", 4)                          = 0
close(6)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
waitpid(-1, 0xbff82aa8, WNOHANG)        = -1 ECHILD (No child processes)
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD RTMIN], 8) = 0
rt_sigaction(SIGCHLD, {0xb7eed7a0, [], 0}, {0xb7eed7a0, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<19>sqlgrey: dbaccess: error: co"..., 118) = 118
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<21>sqlgrey: grey: domain awl ma"..., 98) = 98
open("/etc/hosts", O_RDONLY)            = 6
fcntl64(6, F_GETFD)                     = 0
fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=575, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f58000
read(6, "127.0.0.1       localhost\n69.7.1"..., 4096) = 575
read(6, "", 4096)                       = 0
close(6)                                = 0
munmap(0xb7f58000, 4096)                = 0
open("/etc/hosts", O_RDONLY)            = 6
fcntl64(6, F_GETFD)                     = 0
fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=575, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f58000
read(6, "127.0.0.1       localhost\n69.7.1"..., 4096) = 575
read(6, "", 4096)                       = 0
close(6)                                = 0
munmap(0xb7f58000, 4096)                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
fcntl64(6, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
connect(6, {sa_family=AF_INET, sin_port=htons(5432),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in
progress)
poll([{fd=6, events=POLLOUT|POLLERR, revents=POLLOUT}], 1, -1) = 1
getsockopt(6, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(53553),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
poll([{fd=6, events=POLLOUT|POLLERR, revents=POLLOUT}], 1, -1) = 1
rt_sigprocmask(SIG_BLOCK, [PIPE], [RTMIN], 8) = 0
send(6, "\0\0\0\10\4\322\26/", 8, 0)    = 8
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
poll([{fd=6, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(6, "N", 16384, 0)                  = 1
poll([{fd=6, events=POLLOUT|POLLERR, revents=POLLOUT}], 1, -1) = 1
rt_sigprocmask(SIG_BLOCK, [PIPE], [RTMIN], 8) = 0
send(6, "\0\0\0\'\0\3\0\0user\0sqlgrey\0database\0sq"..., 39, 0) = 39
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
poll([{fd=6, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(6, "R\0\0\0\10\0\0\0\3", 16384, 0) = 9
rt_sigprocmask(SIG_BLOCK, [PIPE], [RTMIN], 8) = 0
send(6, "p\0\0\0\fsqlgrey\0", 13, 0)    = 13
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
poll([{fd=6, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(6, "R\0\0\0\10\0\0\0\0S\0\0\0\36client_encoding\0SQ"..., 16384, 0)
= 166
rt_sigprocmask(SIG_BLOCK, [PIPE], [RTMIN], 8) = 0
send(6, "Q\0\0\0\213UPDATE domain_awl SET last_"..., 140, 0) = 140
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
poll([{fd=6, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(6, "C\0\0\0\rUPDATE 0\0Z\0\0\0\5I", 16384, 0) = 20
time(NULL)                              = 1120614094
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<23>sqlgrey: mail: mail_bucket: "..., 50) = 50
pipe([8, 9])                            = 0
fork()                                  = 24984
close(9)                                = 0
rt_sigaction(SIGINT, {SIG_IGN}, {0xb7eed7a0, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0xb7eed7a0, [], 0}, 8) = 0
waitpid(24984, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 24984
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn()                             = ? (mask now [RTMIN])
rt_sigaction(SIGINT, {0xb7eed7a0, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0xb7eed7a0, [], 0}, NULL, 8) = 0
read(8, "", 4)                          = 0
close(8)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
waitpid(-1, 0xbff82aa8, WNOHANG)        = -1 ECHILD (No child processes)
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD RTMIN], 8) = 0
rt_sigaction(SIGCHLD, {0xb7eed7a0, [], 0}, {0xb7eed7a0, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD RTMIN], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<23>sqlgrey: request: ccert_fing"..., 474) = 474
select(16, [5 7], [7], NULL, NULL)      = 1 (out [7])
write(7, "action=PREPEND X-Greylist: domai"..., 69) = 69
select(16, [5 7], [], NULL, NULL)       = 1 (in [7])
read(7, "", 8192)                       = 0
shutdown(7, 1 /* send */)               = 0
close(7)                                = 0
select(16, [5], [], NULL, NULL)         = 1 (in [5])
accept(5, {sa_family=AF_INET, sin_port=htons(51621),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff81b8c) = -1 EINVAL (Invalid
argument)
_llseek(7, 0, 0xbff81bd0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff81b8c) = -1 EINVAL (Invalid
argument)
_llseek(7, 0, 0xbff81bd0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
fcntl64(7, F_SETFD, FD_CLOEXEC)         = 0
fcntl64(7, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
getsockopt(7, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
getsockname(7, {sa_family=AF_INET, sin_port=htons(2501),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
getpeername(7, {sa_family=AF_INET, sin_port=htons(51621),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
time([1120615029])                      = 1120615029
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<22>sqlgrey: 2005/07/05-21:57:09"..., 95) = 95
time(NULL)                              = 1120615029
select(16, [5 7], [], NULL, NULL)       = 1 (in [7])
read(7, "request=smtpd_access_policy\nprot"..., 8192) = 417
stat64("/etc/sqlgrey/clients_ip_whitelist.local", {st_mode=S_IFREG|0644,
st_size=10, ...}) = 0
stat64("/etc/sqlgrey/clients_fqdn_whitelist.local",
{st_mode=S_IFREG|0644, st_size=3106, ...}) = 0
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<22>sqlgrey: whitelist: murphy.d"..., 64) = 64
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)
write(4, "<21>sqlgrey: whitelist: bounce-d"..., 172) = 172
select(8, [4], NULL, [4], {0, 0})       = 0 (Timeout)

I know that SQLgrey *used to work flawlessly* without lock-ups
previously.  Checking the changelog I see:
* Sat Mar 05 2005 Lionel Bouton <lio...@bo...>
 - 1.5.3 release
 - the cleanup is now done in a separate process to avoid stalling the
service


Is 1.5.3 when the new forking started? 1.5.4 worked FLAWLESSLY on my box
when I installed it in April.

v1.5.9 worked well too.  This locking up JUST started within the last
few weeks and it may not even be related to SQLgrey's code itself.

I did notice that on June 12 (by checking logs) that PGSQL was updated. 
I've since tried reverting back to the old version that was installed
prior to June 12th, just in case that has caused the problem.  The
description for the package shows:

>  This is a transitional package to automatically migrate to the new
>  multicluster/multiversion structure provided by postgresql-common and
>  postgresql-<version>. On installation it will integrate the existing
>  database into this new structure. You can safely remove this package
>  afterwards.


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).

Cheers,

-- 

Ed

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

[Allan J. <al...@no...>]

On 05-Jul-2005, Lionel Bouton wrote:

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

No, never.

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

1.7.0

> OS/Distribution: (uname -a)

Linux coredump 2.6.12-1-686-smp #1 SMP Wed Jun 8 14:50:53 UTC 2005 i686
GNU/Linux (Ubuntu (The Breezy Badger Release) Development Branch)

> Perl version: (see perl -v)

5.8.7

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

0.87

> How many mails/day:

Less than 2000.

-- 
Allan Joergensen

"Don't send lira, God don't want small potatoes"

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

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

Do you have freeze problems: not any more
Latest SQLgrey version used: 1.6.2
OS/Distribution: Fedora Core 4
Perl version: 5.8.6
Net-Server-Multiplex version: 0.88
How many mails/day: 50-100

Stopped hanging after I upgraded to perl-Net-Server 0.88 from 0.87 and
turned up logging to 4.  Was OK with 1.6.1 although I am running 1.6.2
with the no-hang patch you posted now.

-Dave

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

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

Ed Shornock (sqlgrey list) wrote the following on 05.07.2005 19:08 :

>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.
>>
>>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.7.0 then 1.6.2. Reverted back to 1.7.0 with the forking removed. I
>will try 1.6.2 with the most recent patch mentioned in "Freezes,
>follow-up".  Hopefully the vomit bag isn't necessary.
>  
>

In fact it was meant as a bag to put on my head, hiding my shame from
others to see...
But my stomach doesn't feel to good when I think about forgetting to
reap the children after forks...

Lionel.

Re: AW: [Sqlgrey-users] [RELEASE] 1.6.2

[/dev/rob0 <ro...@gm...>]

On Tuesday 05 July 2005 06:58, Michel Bouissou wrote:
> > Until 1.6 is stable, 1.7 will not get much attention.
>
> I'm personally not in any hurry as the current 1.7.0 works perfect
> for me :-)

Likewise.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

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

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

Lionel Bouton wrote:
> If I'm right, I'll need a brown-paper bag.
> 
> I'm interested by the result of the attached patch on configurations
> where freezes occur...
> 
> cd /usr/sbin;
> cp sqlgrey sqlgrey.sav
> 
> patch -p0 < sqlgrey-zombies.patch
> 
> 

I've reverted back to a pristine 1.6.2, applied this patch, turned the
log level up to 4, and i'm strace'ing the sqlgrey process to a log file.

I'll keep you posted...

Cheers,

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

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

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.
> 
> 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.7.0 then 1.6.2. Reverted back to 1.7.0 with the forking removed. I
will try 1.6.2 with the most recent patch mentioned in "Freezes,
follow-up".  Hopefully the vomit bag isn't necessary.

> OS/Distribution: (uname -a)
Debian Sid (unstable)
$ uname -a
Linux darkside 2.6.12.2-p4.20050704 #1 Mon Jul 4 09:54:00 EDT 2005 i686
GNU/Linux

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

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

> 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:
I think 1,500-2,000 is the most that's come into my 'personal server' at
home. Recently it's been only 700 emails or so, daily.

> I hope this will bring some pattern.

Me too, but I think we'd need another person besides me to have the
problem...hehe.

Cheers,

-- 
Ed

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

[Michael S. <Mic...@lr...>]

On Tue, 5 Jul 2005, Lionel Bouton wrote:

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

Never.

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

heavily customized version of 1.7.0 :-)

> OS/Distribution: (uname -a)

Linux lxmhs18 2.6.5-7.147-smp #1 SMP Thu Jan 27 09:19:29 UTC 2005 i686 i686 i386 GNU/Linux

> Perl version: (see perl -v)

This is perl, v5.8.3 built for i586-linux-thread-multi

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

0.88

> How many mails/day:

Since greylisting only 300.000 incoming emails per day.
About 1.000.000 triples per day (permitted + rejected + early reconnect +
throttled)

Michael Storz
-------------------------------------------------
Leibniz-Rechenzentrum   !   <mailto:St...@lr...>
Barer Str. 21           !   Fax: +49 89 2809460
80333 Muenchen, Germany !   Tel: +49 89 289-28840

[Sqlgrey-users] Freezes, follow-up

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

If I'm right, I'll need a brown-paper bag.

I'm interested by the result of the attached patch on configurations
where freezes occur...

cd /usr/sbin;
cp sqlgrey sqlgrey.sav

patch -p0 < sqlgrey-zombies.patch

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

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

Do you have freeze problems: no
Latest SQLgrey version used: 1.6.2
OS/Distribution: Linux eric 2.6.9-gentoo-r12 #1 Fri Dec 24 13:20:09 GMT 
2004 i686 AMD Athlon(TM) XP 2500+ AuthenticAMD GNU/Linux
Perl version:  v5.8.6 built for i586-linux
Net-Server-Multiplex version: 0.87
How many mails/day: 600


Regards
Ray Booysen

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

[Michel B. <mi...@bo...>]

Le Mardi 05 Juillet 2005 14:05, Lionel Bouton a =E9crit :
>
> Could you please fill in the following:
>
> Do you have freeze problems: (yes/no)

No, and not with any SQLgrey version AFAIR.

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

1.7.0

> OS/Distribution: (uname -a)

Linux totor.bouissou.net 2.4.28-0.rc1.1.1MiBevmsmdkc5 #2 ven d=E9c 10 12:=
28:44=20
CET 2004 i686 AMD Athlon(tm) XP 2000+ unknown GNU/Linux

(That's a very heavily customized mix of Mdk 10.0 /10.1 / 10.2)

> Perl version: (see perl -v)

[michel@totor tests+docs]$ perl -v
This is perl, v5.8.6 built for i386-linux

(Upgraded 3 days ago, using Perl 5.8.5 before with no problems)

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

0.87

> How many mails/day:

Small server, between 1,000 - 2,000 mails a day.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

endonasodigital : se dit de quelque chose d'extr=E8mement facile
	(les doigts dans le nez)=20

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

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

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.

Could you please fill in the following:

Do you have freeze problems: (yes/no)
Latest SQLgrey version used: (1.6.[012] / 1.7.0)
OS/Distribution: (uname -a)
Perl version: (see perl -v)
Net-Server-Multiplex version: (perl -MNet::Server::Multiplex -e 'print
$Net::Server::Multiplex::VERSION')
How many mails/day:

I hope this will bring some pattern.

Lionel.

Re: AW: [Sqlgrey-users] [RELEASE] 1.6.2

[Michel B. <mi...@bo...>]

Le Mardi 05 Juillet 2005 13:40, Lionel Bouton a =E9crit :
>
> My main concern is to find the source of the freeze some of you get wit=
h
> 1.6/1.7 which are clearly related to the new forked cleanup. Until 1.6
> is stable, 1.7 will not get much attention.

I'm personally not in any hurry as the current 1.7.0 works perfect for me=
 :-)

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

Re: AW: AW: [Sqlgrey-users] [RELEASE] 1.6.2

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

Fra...@co... wrote the following on 05.07.2005 13:43 :

>>??? I see it right now at
>>http://sourceforge.net/project/showfiles.php?group_id=113566
>>
>>    
>>
>Oh. I used the Link from the message from Lionel
>http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=1554
>92&release_id=339685
>and this seemded to be a view only on version 1.6.x
>  
>

Yes, I use a direct link to the release each time.
I regularly clean the old releases (particularly the buggy ones) though.
I try to maintain links to the last releases of each subversion.

Lionel.

AW: AW: [Sqlgrey-users] [RELEASE] 1.6.2

[<Fra...@co...>]

> ??? I see it right now at
> http://sourceforge.net/project/showfiles.php?group_id=113566
> 
Oh. I used the Link from the message from Lionel
http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=1554
92&release_id=339685
and this seemded to be a view only on version 1.6.x

Re: AW: [Sqlgrey-users] [RELEASE] 1.6.2

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

Michel Bouissou wrote the following on 05.07.2005 13:33 :

>The question I would like to ask is rather : Are the latest improvements to 
>the "stable" 2.6.x branch as well committed to the 1.7.x branch ?
>
>  
>

They are mostly in my tree, you could fetch them from CVS. They aren't
urgent enough to make a 1.7.1 release. I've 5 patches from Michael Storz
for 1.7.x I have to evaluate too.
My main concern is to find the source of the freeze some of you get with
1.6/1.7 which are clearly related to the new forked cleanup. Until 1.6
is stable, 1.7 will not get much attention.

Lionel.