Re: many processes open
On Mon, Jul 31, 2000 at 12:03:12PM +0200, Marco Benetton wrote: ! @4000398064413962161c delivery 303: deferral: bin/qmail-queue:_error_in_loading_shared_libraries:_libc.so.6:_cannot_open_shared_object_file:_Error_23/Unable_to_forward_message:_qq_temporary_problem_(#4.3.0)./ Error 23, in Linux (not such a big assumption seeing that your libc is called libc.so.6 :-)), is ENFILE (File table overflow). Essentially, your system cannot open any more files. It's just a temporary situation, just wait it out and hope you don't get more SMTP connections. :-) ! I have set the file concurencyremote=20 and concurencylocal=10 ! but how is possible that I have 328 qmail-smtpd process in a time. concurrencyremote and concurrencylocal do not affect how many qmail-smtpd processes can be run. Having 328 connections seems to me to be doable only if you invoke qmail-smtpd via inetd (see http://cr.yp.to/docs/inetd.html). Try using tcpserver from the ucspi-tcp package instead. It has a concurrency limit of 40, by default. See http://cr.yp.to/ucspi-tcp.html. Good luck, ---Chris K. -- Chris, the Young One |_ but what's a dropped message between friends? Auckland, New Zealand |_ this is UDP, not TCP after all ;) ---John H. http://cloud9.hedgee.com/ |_ Robinson, IV PGP: 0xCCC6114E/0x706A6AAD |_
RE: many processes open
Chris, >your system cannot open any more files. It's just a temporary situation, >just wait it out and hope you don't get more SMTP connections. :-) Perhaps checkout ulimit -n, which refers to the max. no. of file descriptors - With Solaris using ulimit -n xxx before calling qmail-start is appropriate, but with Linux it looks like there is no upper limit (bash offers you a ulimit command to check this). Maybe there's a hard-coded f.d. limit in the kernel?? >concurrencyremote and concurrencylocal do not affect how many >qmail-smtpd processes can be run. Having 328 connections seems to >me to be doable only if you invoke qmail-smtpd via inetd (see >http://cr.yp.to/docs/inetd.html). I disagree: I've setup machines handling plenty of connections using tcpserver - which is, I feel, a far more appropriate way of calling qmail-smtpd. Have you come across particular problems with tcpserver that lead you to the 'Need inetd' conclusion? If it's an issue of timeouts, or [very] slow connections, that should be the familiar old cookie of the -R and -H options to tcpserver - as someone who moved from inetd to tcpserver myself, this is a problem I remember well cheers, Andrew. -- From: Chris, the Young One[SMTP:[EMAIL PROTECTED]] Sent: 31 July 2000 14:49 To: [EMAIL PROTECTED] Subject:Re: many processes open On Mon, Jul 31, 2000 at 12:03:12PM +0200, Marco Benetton wrote: ! @4000398064413962161c delivery 303: deferral: bin/qmail-queue:_error_in_loading_shared_libraries:_libc.so.6:_cannot_open_shared_object_file:_Error_23/Unable_to_forward_message:_qq_temporary_problem_(#4.3.0)./ Error 23, in Linux (not such a big assumption seeing that your libc is called libc.so.6 :-)), is ENFILE (File table overflow). Essentially, your system cannot open any more files. It's just a temporary situation, just wait it out and hope you don't get more SMTP connections. :-) ! I have set the file concurencyremote=20 and concurencylocal=10 ! but how is possible that I have 328 qmail-smtpd process in a time. concurrencyremote and concurrencylocal do not affect how many qmail-smtpd processes can be run. Having 328 connections seems to me to be doable only if you invoke qmail-smtpd via inetd (see http://cr.yp.to/docs/inetd.html). Try using tcpserver from the ucspi-tcp package instead. It has a concurrency limit of 40, by default. See http://cr.yp.to/ucspi-tcp.html. Good luck, ---Chris K.
Re: many processes open
On Mon, Jul 31, 2000 at 08:03:41PM +, [EMAIL PROTECTED] wrote: ! >your system cannot open any more files. It's just a temporary situation, ! >just wait it out and hope you don't get more SMTP connections. :-) ! Perhaps checkout ulimit -n, which refers to the max. no. of file descriptors ! - With Solaris using ulimit -n xxx before calling qmail-start is appropriate, ! but with Linux it looks like there is no upper limit (bash offers you a ulimit ! command to check this). Maybe there's a hard-coded f.d. limit in the kernel?? Linux 2.2's global fd limit (as opposed to the per-process fd limit which you set with ``ulimit -n'') isn't hard-coded; you can set it via /proc/sys/fs/file-max. ! I disagree: I've setup machines handling plenty of connections ! using tcpserver - which is, I feel, a far more appropriate way of ! calling qmail-smtpd. You can set tcpserver's concurrency to 400, should you so wish. But by default it will handle only 40, which was why I found 328 a bit strange. (Maybe it's because my mail server doesn't get that many SMTP connections, not enough to merit altering the concurrency limit.) ! Have you come across particular problems ! with tcpserver that lead you to the 'Need inetd' conclusion? I didn't say you ``need'' inetd. My conclusion was that with inetd, there is effectively _no_ concurrency limit, which in my opinion is a Bad Thing. ---Chris K. -- Chris, the Young One |_ Never brag about how your machines haven't been Auckland, New Zealand |_ hacked, or your code hasn't been broken. It's http://cloud9.hedgee.com/ |_ guaranteed to bring the wrong kind of PGP: 0xCCC6114E/0x706A6AAD |_ attention. ---Neil Schneider
Re: many processes open
"Chris, the Young One" <[EMAIL PROTECTED]> wrote: > ! Have you come across particular problems > ! with tcpserver that lead you to the 'Need inetd' conclusion? > > I didn't say you ``need'' inetd. My conclusion was that with inetd, > there is effectively _no_ concurrency limit, which in my opinion is > a Bad Thing. >From inetd(8): The optional `max'' suffix (separated from `wait'' or `nowait'' by a dot) specifies the maximum number of server instances that may be spawned from inetd within an interval of 60 seconds. When omitted, `max'' defaults to 40. By Töns -- Linux. The dot in /.
Re: many processes open
Toens Bueker <[EMAIL PROTECTED]> wrote: >From inetd(8): > >The optional `max'' suffix (separated from `wait'' or `nowait'' by a dot) >specifies the maximum number of server instances that may be spawned from >inetd within an interval of 60 seconds. When omitted, `max'' defaults to 40. That's a rate limit, not a concurrency limit. -Dave
