Menu
▾
▴
sqlgrey-users
|
From: Lionel B. <lio...@bo...> - 2005-07-05 12:05:01
|
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. |
|
From: Michel B. <mi...@bo...> - 2005-07-05 12:13:37
|
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 |
|
From: Ray B. <rj_...@rj...> - 2005-07-05 13:07:34
|
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 |
|
From: Michael S. <Mic...@lr...> - 2005-07-05 14:21:44
|
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 |
|
From: Ed S. (s. list) <sq...@cr...> - 2005-07-05 17:08:59
|
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 |
|
From: Lionel B. <lio...@bo...> - 2005-07-05 17:50:58
|
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. |
|
From: Ed S. (s. list) <sq...@cr...> - 2005-07-11 17:31:31
|
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
|
|
From: David R. <dr...@gm...> - 2005-07-05 18:25:51
|
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 |
|
From: David R. <dr...@gm...> - 2005-07-06 19:32:46
|
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 |
|
From: Allan J. <al...@no...> - 2005-07-06 07:32:26
|
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" |
|
From: Brett H. <ha...@gm...> - 2005-07-07 06:54:15
|
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 > |
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-25 17:45:19
|
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 |
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-25 18:01:02
|
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
|
|
From: Lionel B. <lio...@bo...> - 2005-07-25 19:18:21
|
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. |
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-26 05:50:15
|
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 |
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-26 09:04:37
|
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
|
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-26 10:15:47
|
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
|
|
From: Lionel B. <lio...@bo...> - 2005-07-26 11:25:35
|
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
|
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-26 16:27:57
Attachments:
cleanup.patch
|
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
|
|
From: Lionel B. <lio...@bo...> - 2005-07-26 17:46:13
|
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.
|
|
From: Rupa S. (lists) <rup...@ru...> - 2005-07-28 20:51:55
|
On 7/26/2005 10:46 AM, Lionel Bouton wrote: > 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... Glad to be of help -- I know I've done similar things during the 'cleanup' phase after doing some coding. > 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. Sounds good to me. I've been running this way now for a couple of days and have not had a lockup. > 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. > Great! The lockup with async came on suddenly so I don't know if it'll magically fix itself. When you have something to test I'll give it a go. -- -Rupa |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X