Re: [courier-users] mta hanging reading smtpaccess.dat
Alessandro Vesely wrote: I don't understand those repeated read() calls returning 0. It should mean end of file, thus there should be no point in insisting. For EINTR, read should return a negative number, and strace should report that. I think you're right. You can see Debian's patch here: http://patch-tracking.debian.net/patch/series/view/gdbm/1.8.3-3/05_handle-short-read They've introduced a while loop that will continue if bytes were read, or if errno == EINTR. However, they check errno even if the return value of read() doesn't indicate that they should. Since read() won't reset errno on EOF, this creates an infinite loop if errno was already EINTR. I'm still not enlightened as to the cause of the problem, but it seems clear that gdbm on Debian is broken. An interested party should file a new bug report and ask them to fix this properly or take it out, and to push the changes to the gdbm maintainer for review. Like their SSL blunder, I believe that someone who knows what they're doing might be able to set them straight. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira wrote: Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 That's pretty odd. Are your dat files also on Reiser filesystems? No, its on ext3. Do you have any cron jobs that call makesmtpaccess? I wonder if they might be stomping on each other's output. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira wrote:
At a random time (may be hours, days or weeks) the main couriertcpd
keeps running and accepting connections (until the max clients are
reached) but the childs processess never ends.
[...]
2) strace for a child couriertcpd process while on start of the lock
[...]
17:46:43.758570 read(4, ..., 2446) = 0
17:46:43.758654 read(4, ..., 2446) = 0
17:46:43.758762 read(4,
\1\0\0\0\0\0\0\0\216\t\0\0\0\0\0\0r6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
2446) = 2446
17:46:43.759082 getsockname(5, {sa_family=AF_INET6, sin6_port=htons(25),
If that is called before getsockname, it means it is in bdbobj_open,
right? Are processes starving because of some locking mechanism?
I think at this point the db (smtpaccess.dat) is already open, the hang is
when the process makes queries.
As I could trace:
. tcpd/tcpd.c:
function accepted calls allowaccess
I saw sox_getsockname is called before allowaccess, thence my
guess that it was in the former call. However, yes, there is a further
call to sox_getsockname in run, after allowaccess in the child.
function allowaccess calls doallowaccess
function doallowaccess calls chkaccess
. tcpd/tcpdaccess.c:
function chkacess calls dbobj_fetch
Mind that you have twice #define dbobj_fetch in dbobj.h
. bdbobj/bdbobj.c:
function dbobj_fetch calls doquery
** The process get locked on a infinity loop at doquery function (
for (;;) )
function doquery calls dofetch
function dofetch calls (*obj-dbf-get)
From here I could not trace anymore, but I guess it is a call for the
gdbm library.
The _db-4_ library, actually. dbf-get gets mapped to an interface
function in the call to db_create (e.g. __db_get_pp).
However, your further posts imply you are using gdbm, thus you should
check gdbmobj/gdbmobj.c: function gdbmobj_fetch. Or have you been
switching from bdb to gdbm during the weekend?
The fetch is never returning successfully. So the function get locked on
the loop.
I don't understand those repeated read() calls returning 0. It should
mean end of file, thus there should be no point in insisting. For
EINTR, read should return a negative number, and strace should report
that. (My strace looks quite similar to your normal operation one,
however I have pread rather than read, and no lseek, with bdb4.4)
Good luck
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
If that is called before getsockname, it means it is in bdbobj_open, right? Are processes starving because of some locking mechanism? I think at this point the db (smtpaccess.dat) is already open, the hang is when the process makes queries. As I could trace: . tcpd/tcpd.c: function accepted calls allowaccess I saw sox_getsockname is called before allowaccess, thence my guess that it was in the former call. However, yes, there is a further call to sox_getsockname in run, after allowaccess in the child. The call for sox_getsockname before allowaccess only happens if accesslocal is set. And its not on my system. function allowaccess calls doallowaccess function doallowaccess calls chkaccess . tcpd/tcpdaccess.c: function chkacess calls dbobj_fetch Mind that you have twice #define dbobj_fetch in dbobj.h . bdbobj/bdbobj.c: function dbobj_fetch calls doquery ** The process get locked on a infinity loop at doquery function ( for (;;) ) function doquery calls dofetch function dofetch calls (*obj-dbf-get) From here I could not trace anymore, but I guess it is a call for the gdbm library. The _db-4_ library, actually. dbf-get gets mapped to an interface function in the call to db_create (e.g. __db_get_pp). However, your further posts imply you are using gdbm, thus you should check gdbmobj/gdbmobj.c: function gdbmobj_fetch. Or have you been switching from bdb to gdbm during the weekend? I had always use gdbm. I do not know yet how to switch to bdb, but if my fix on gdbm do not work I will try to move. The fetch is never returning successfully. So the function get locked on the loop. I don't understand those repeated read() calls returning 0. It should mean end of file, thus there should be no point in insisting. For EINTR, read should return a negative number, and strace should report that. (My strace looks quite similar to your normal operation one, however I have pread rather than read, and no lseek, with bdb4.4) I think this is the bug on Debian gdbm package. The patch they made to the official release may ignore EINTR. I will test my package for more a few days and if there is no more hangs I will repot to Debian bugtrack. Thanks for pointing me the way. Marcus -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Sam Varshavchik wrote: Marcus Pereira writes: The problem occour in all servers. I already reinstall some them. Some run Debian 32bits, Some Debian 64bits. Some are fresh install, some are old install. But the problem happens in all them. Sounds like a corrupted smtpaccess.dat file. A simple reinstall won't make a difference. Run 'makesmtpaccess' to rebuild the smtpaccess.dat file. That should take care of it. Its not a corrupted smtpaccess.dat. I already changed it and rebuild it lot of times. Last week I made a cleanup and only left arround 40 lines on the smtpaccess file. Just rebuild it today and I already face the problem again. For some reason the hangs become more frequenty this month. Except that it's been happening for more than a year, and occurs randomly. My guess is a db library bug. I'd try a different library (probably gdbm). I could do that, but how? I am using libgdbm 1.8.3 Marcus Pereira -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira pisze: Sam Varshavchik wrote: [...] Except that it's been happening for more than a year, and occurs randomly. My guess is a db library bug. I'd try a different library (probably gdbm). I could do that, but how? I am using libgdbm 1.8.3 Hello Marcus, We also noticed that problem with smtpaccess.dat file many times. We are using libgdbm 1.8.3 (from Ubuntu package libgdbm3 1.8.3-3) like you. It's the most recently version of libgdbm for Debian and Ubuntu. My best regards, Pawel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
At a random time (may be hours, days or weeks) the main couriertcpd
keeps running and accepting connections (until the max clients are
reached) but the childs processess never ends.
[...]
2) strace for a child couriertcpd process while on start of the lock
[...]
17:46:43.758570 read(4, ..., 2446) = 0
17:46:43.758654 read(4, ..., 2446) = 0
17:46:43.758762 read(4,
\1\0\0\0\0\0\0\0\216\t\0\0\0\0\0\0r6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
2446) = 2446
17:46:43.759082 getsockname(5, {sa_family=AF_INET6, sin6_port=htons(25),
If that is called before getsockname, it means it is in bdbobj_open,
right? Are processes starving because of some locking mechanism?
I think at this point the db (smtpaccess.dat) is already open, the hang is
when
the process makes querys.
As I could trace:
. tcpd/tcpd.c:
function accepted calls allowaccess
function allowaccess calls doallowaccess
function doallowaccess calls chkaccess
. tcpd/tcpdaccess.c:
function chkacess calls dbobj_fetch
. bdbobj/bdbobj.c:
function dbobj_fetch calls doquery
** The process get locked on a infinity loop at doquery function (
for (;;) )
function doquery calls dofetch
function dofetch calls (*obj-dbf-get)
From here I could not trace anymore, but I guess it is a call for the
gdbm library.
The fetch is never returning successfully. So the function get locked on
the loop.
May be its some lock at the file or a bug at the library, but since I
could not trace more
I send the message to the list.
Is it bdb4? Is it NFS mounted?
(http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/remote.html)
No, all smtpaccess.dat files are local.
Some mailboxes are NFS mounted, but at the point of the hang no NFS mounted
file is accessed.
Marcus
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Except that it's been happening for more than a year, and occurs randomly. My guess is a db library bug. I'd try a different library (probably gdbm). I could do that, but how? I am using libgdbm 1.8.3 Hello Marcus, We also noticed that problem with smtpaccess.dat file many times. We are using libgdbm 1.8.3 (from Ubuntu package libgdbm3 1.8.3-3) like you. It's the most recently version of libgdbm for Debian and Ubuntu. My best regards, Pawel Hi Pawel, I have servers using Debian libdbdm3 1.8.3-3 and 1.8.3-4. Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 I feel suspecious about the fix they made. I removed the patch and rebuild the package. Its now running on 4 of my servers, no problem at all but still too early to say this is the problem. If you want to try my package: http://dl.task.net.br/libgdbm3_1.8.3-4.1_amd64.deb for Debian 64. http://dl.task.net.br/libgdbm3_1.8.3-4.1_i386.deb for Debian 32. Marcus Pereira -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira wrote: Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 I feel suspecious about the fix they made. I removed the patch and rebuild the package. Its now running on 4 of my servers, no problem at all but still too early to say this is the problem. That's pretty odd. Are your dat files also on Reiser filesystems? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 I feel suspecious about the fix they made. I removed the patch and rebuild the package. Its now running on 4 of my servers, no problem at all but still too early to say this is the problem. That's pretty odd. Are your dat files also on Reiser filesystems? No, its on ext3. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 I feel suspecious about the fix they made. I removed the patch and rebuild the package. Its now running on 4 of my servers, no problem at all but still too early to say this is the problem. That's pretty odd. Are your dat files also on Reiser filesystems? No, its on ext3. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira pisze: Hi Pawel, I have servers using Debian libdbdm3 1.8.3-3 and 1.8.3-4. Studing libdbm3 package on Debian I found this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274417 I feel suspecious about the fix they made. I removed the patch and rebuild the package. Its now running on 4 of my servers, no problem at all but still too early to say this is the problem. If you want to try my package: http://dl.task.net.br/libgdbm3_1.8.3-4.1_amd64.deb for Debian 64. http://dl.task.net.br/libgdbm3_1.8.3-4.1_i386.deb for Debian 32. Thanks for the tip, Marcus! I can take a look at your packages, but I don't know when the problem will occur again, of course. BTW, we also have ext3 filesystem :) Good night, P. PS. Here in Poland we have TASK too. It's Polish acronym for Tri-City Academic Computer Network :D -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira wrote:
At a random time (may be hours, days or weeks) the main couriertcpd
keeps running and accepting connections (until the max clients are
reached) but the childs processess never ends.
[...]
2) strace for a child couriertcpd process while on start of the lock
[...]
17:46:43.758570 read(4, ..., 2446) = 0
17:46:43.758654 read(4, ..., 2446) = 0
17:46:43.758762 read(4,
\1\0\0\0\0\0\0\0\216\t\0\0\0\0\0\0r6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
2446) = 2446
17:46:43.759082 getsockname(5, {sa_family=AF_INET6, sin6_port=htons(25),
If that is called before getsockname, it means it is in bdbobj_open,
right? Are processes starving because of some locking mechanism?
Is it bdb4? Is it NFS mounted?
(http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/remote.html)
Gordon Messmer wrote:
Except that it's been happening for more than a year, and occurs
randomly. My guess is a db library bug. I'd try a different library
(probably gdbm).
Id bdb buggy?
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] mta hanging reading smtpaccess.dat
Hi,
I have an email system with more then 35000 accounts and that process arround
38 messages a day on 4 servers. For more then an year I am facing random
hangs on the smtp server.
At a random time (may be hours, days or weeks) the main couriertcpd keeps
running and accepting connections (until the max clients are reached) but the
childs processess never ends.
Today I get some usefull strace outputs that may help to solve the problem.
The child process get locked on a infinity loop reading the smtpaccess.dat.
All the child couriertcpd I strace are on the same loop.
smtpaccess.dat was not modified.
The problem occour in all servers. I already reinstall some them. Some run
Debian 32bits, Some Debian 64bits. Some are fresh install, some are old
install. But the problem happens in all them.
I try to debug the source code to find where is the problema but it seems too
complex for me. May be you (Sam?) can help me on what I can to to solve this
problem?
Marcus
1) strace for a child couriertcpd process during normal operation
17:46:05.482106 rt_sigaction(SIGCHLD, {SIG_DFL}, {0x404ae0, [CHLD],
SA_RESTORER|SA_RESTART, 0x7f4144f8af60}, 8) = 0
17:46:05.482278 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
17:46:05.482683 brk(0x2503000) = 0x2503000
17:46:05.482974 brk(0x2524000) = 0x2524000
17:46:05.483454 brk(0x2545000) = 0x2545000
17:46:05.483729 lseek(4, 8192, SEEK_SET) = 8192
17:46:05.484210 read(4, \0\0\0\0\r\0\0\0\31\0\0\0\271\3627
216.\2474\0\0\0\0\0\0\16\0\0\0\31..., 4096) = 4096
17:46:05.484686 getsockname(5, {sa_family=AF_INET6, sin6_port=htons(25),
inet_pton(AF_INET6, :::74.86.76.42, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 0
17:46:05.485206 open(/etc/resolv.conf, O_RDONLY) = 6
.
.
. normal process end..
-
2) strace for a child couriertcpd process while on start of the lock
--
17:46:43.742191 rt_sigaction(SIGCHLD, {SIG_DFL}, {0x404ae0, [CHLD],
SA_RESTORER|SA_RESTART, 0x7f4144f8af60}, 8) = 0
17:46:43.743147 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
17:46:43.748307 brk(0x2503000) = 0x2503000
17:46:43.753416 brk(0x2524000) = 0x2524000
17:46:43.753745 brk(0x2545000) = 0x2545000
17:46:43.754507 lseek(4, 8192, SEEK_SET) = 8192
17:46:43.754836 read(4, 201.17.129.83allow,SIZELIMIT=5242..., 4096) = 1650
17:46:43.755069 read(4, ..., 2446) = 0
17:46:43.756458 read(4, ..., 2446) = 0
17:46:43.756556 read(4, ..., 2446) = 0
17:46:43.756994 read(4, ..., 2446) = 0
17:46:43.757080 read(4, ..., 2446) = 0
17:46:43.757188 read(4, ..., 2446) = 0
17:46:43.757276 read(4, ..., 2446)= 0
17:46:43.757367 read(4, ..., 2446)= 0
17:46:43.757452 read(4, ..., 2446) = 0
17:46:43.757534 read(4, ..., 2446) = 0
17:46:43.757617 read(4, ..., 2446) = 0
17:46:43.757703 read(4, ..., 2446)= 0
17:46:43.757794 read(4, ..., 2446) = 0
17:46:43.757877 read(4, ..., 2446) = 0
17:46:43.757960 read(4, ..., 2446) = 0
17:46:43.758047 read(4, ..., 2446) = 0
17:46:43.758155 read(4, ..., 2446) = 0
17:46:43.758260 read(4, ..., 2446) = 0
17:46:43.758570 read(4, ..., 2446) = 0
17:46:43.758654 read(4, ..., 2446) = 0
17:46:43.758762 read(4,
\1\0\0\0\0\0\0\0\216\t\0\0\0\0\0\0r6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 2446)
= 2446
17:46:43.759082 getsockname(5, {sa_family=AF_INET6, sin6_port=htons(25),
inet_pton(AF_INET6, :::74.86.76.42, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28]) = 0
17:46:43.759258 open(/etc/resolv.conf, O_RDONLY) = 6
.
.
.
. normal process end..
--
3) strace for a child couriertcpd during the smtp hang
-
17:46:49.944384 rt_sigaction(SIGCHLD, {SIG_DFL}, {0x404ae0, [CHLD],
SA_RESTORER|SA_RESTART, 0x7f4144f8af60}, 8) = 0
17:46:49.950918 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
17:46:49.951420 brk(0x2503000) = 0x2503000
17:48:05.794865 brk(0x2524000) = 0x2524000
17:48:05.795256 brk(0x2545000) = 0x2545000
17:48:45.322594 lseek(4, 8192, SEEK_SET) = 8192
17:48:45.322770 read(4, 201.17.129.83allow,SIZELIMIT=5242..., 4096) = 1650
17:48:45.322967 read(4, ..., 2446) = 0
17:48:45.323220 read(4, ..., 2446) = 0
17:48:45.323390 read(4, ..., 2446) = 0
17:48:45.323529 read(4, ..., 2446)= 0
17:48:45.323675 read(4, ..., 2446)= 0
17:48:45.323812 read(4, ..., 2446) = 0
17:48:45.323937 read(4, ..., 2446) = 0
17:48:45.324074 read(4, ..., 2446) = 0
17:48:45.324215 read(4, ..., 2446)= 0
17:48:45.324377 read(4, ..., 2446) = 0
.
.
. until I restart courier-mta
-
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
Re: [courier-users] mta hanging reading smtpaccess.dat
Marcus Pereira writes: The problem occour in all servers. I already reinstall some them. Some run Debian 32bits, Some Debian 64bits. Some are fresh install, some are old install. But the problem happens in all them. Sounds like a corrupted smtpaccess.dat file. A simple reinstall won't make a difference. Run 'makesmtpaccess' to rebuild the smtpaccess.dat file. That should take care of it. pgpgSlVZsQEFB.pgp Description: PGP signature -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] mta hanging reading smtpaccess.dat
Sam Varshavchik wrote: Marcus Pereira writes: The problem occour in all servers. I already reinstall some them. Some run Debian 32bits, Some Debian 64bits. Some are fresh install, some are old install. But the problem happens in all them. Sounds like a corrupted smtpaccess.dat file. A simple reinstall won't make a difference. Run 'makesmtpaccess' to rebuild the smtpaccess.dat file. That should take care of it. Except that it's been happening for more than a year, and occurs randomly. My guess is a db library bug. I'd try a different library (probably gdbm). -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
