On Thursday 06 February 2003 12:10 pm, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Feb 2003, Dave McMurtrie wrote:
> > Would this actually work anyway? If the parent were to pass a file
>
> You can send descriptors over sockets if your unix kernel supports it.
> Linux does, and apparently so d
On Thu, 6 Feb 2003, Igor Brezac wrote:
> Not that simple. ;) Check out http://www.kohala.com/start/apue.html.
Got it. I was just reading about stream pipes elsewhere and saw there was
an ioctl() to handle passing file descriptors through them. Looks like
there are other ways, as well. Thanks
On Thu, 6 Feb 2003, Dave McMurtrie wrote:
> On Thu, 6 Feb 2003, Henrique de Moraes Holschuh wrote:
>
> > On Wed, 05 Feb 2003, Igor Brezac wrote:
> > > > descriptors down to a child via a unix domain socket using sendmsg() or
> > > > recvmsg(). In this case the master accepts the connection, passe
On Thu, 06 Feb 2003, Dave McMurtrie wrote:
> Would this actually work anyway? If the parent were to pass a file
You can send descriptors over sockets if your unix kernel supports it. Linux
does, and apparently so does Solaris.
Anyway, I dislike the idea of losing preforks heavily, it is bound to
On Thu, 6 Feb 2003, Henrique de Moraes Holschuh wrote:
> On Wed, 05 Feb 2003, Igor Brezac wrote:
> > > descriptors down to a child via a unix domain socket using sendmsg() or
> > > recvmsg(). In this case the master accepts the connection, passes the
> > > descriptor to a child via sendmsg(), clos
On Thu, 6 Feb 2003, Henrique de Moraes Holschuh wrote:
> On Wed, 05 Feb 2003, Igor Brezac wrote:
> > > descriptors down to a child via a unix domain socket using sendmsg() or
> > > recvmsg(). In this case the master accepts the connection, passes the
> > > descriptor to a child via sendmsg(), clo
On Wed, 05 Feb 2003, Igor Brezac wrote:
> > descriptors down to a child via a unix domain socket using sendmsg() or
> > recvmsg(). In this case the master accepts the connection, passes the
> > descriptor to a child via sendmsg(), closes the socket (the child should now
> > be servicing it), and go
On Wed, 5 Feb 2003, Jeremy Rumpf wrote:
>
> > Hmmm... what does Sendmail do? It's got lots of children, but still
> > manages to refuse connections when it gets busy (RefuseLA)... I kinda
> > like that behavior. I definitely like it better than keeping more and
> > more sockets open.
> >
> > -
> Hmmm... what does Sendmail do? It's got lots of children, but still
> manages to refuse connections when it gets busy (RefuseLA)... I kinda
> like that behavior. I definitely like it better than keeping more and
> more sockets open.
>
> --
> Stephen L. Ulmer [EMAI
From: "Stephen L. Ulmer" <[EMAIL PROTECTED]>
Date: Wed, 05 Feb 2003 16:57:15 -0500
[...]
Hmmm... what does Sendmail do? It's got lots of children, but still
manages to refuse connections when it gets busy (RefuseLA)... I kinda
like that behavior. I definitely like it better than k
-- "Stephen L. Ulmer" <[EMAIL PROTECTED]> is rumored to have mumbled on
Mittwoch, 5. Februar 2003 16:57 Uhr -0500 regarding Re: imapd's hang when
maxchild count is reached:
Hmmm... what does Sendmail do? It's got lots of children, but still
manages to refuse con
"leg+" == Lawrence Greenfield <[EMAIL PROTECTED]> writes:
leg+> Yes, that would be desirable. The easiest way of doing this
leg+> would be to close the socket used to accept() new
leg+> connections. However, it's open in all of the children, so
leg+> closing it is infeasible.
leg+> Th
On Wed, 05 Feb 2003 15:21:26 -0500
Scott Adkins <[EMAIL PROTECTED]> wrote:
> I solved this problem a long time ago by passing an environment variable
> from the master process to the child process when the child process is
> spawned indicating that the server is full. I used CYRUS_MAXCHILD, and
>
I solved this problem a long time ago by passing an environment variable
from the master process to the child process when the child process is
spawned indicating that the server is full. I used CYRUS_MAXCHILD, and
the child process already checks for the CYRUS_VERBOSE variable when it
starts in o
Date: Wed, 05 Feb 2003 18:51:35 +0100
From: Sebastian Hagedorn <[EMAIL PROTECTED]>
[...]
Wouldn't it be possible (and better) to refuse further connections instead
of having to wait for them to time out? Maybe I haven't thought this
through properly, but it seems to me as if that w
--On Wednesday, February 05, 2003 12:22:06 -0500 Lawrence Greenfield
<[EMAIL PROTECTED]> wrote:
They seem to be the same for all of the processes ...
This is a totally normal backtrace for "waiting for more input from
the client". Are you sure that your perl script is working correctly?
You
Date: Wed, 05 Feb 2003 14:04:38 +0100
From: Sebastian Hagedorn <[EMAIL PROTECTED]>
[...]
0x402e3bee in __select () from /lib/i686/libc.so.6
(gdb) bt
#0 0x402e3bee in __select () from /lib/i686/libc.so.6
#1 0x0811a994 in __DTOR_END__ ()
#2 0x0808410c in getword ()
#3 0x08
--On Saturday, February 01, 2003 16:34:51 -0500 Lawrence Greenfield
<[EMAIL PROTECTED]> wrote:
Probably grabbing the "strace" and a gdb backtrace of a "hung" imapd
process would help figure out what they're waiting for. Might as well
do master, too.
OK, I just recreated the situation. The imapd
-- Lawrence Greenfield <[EMAIL PROTECTED]> is rumored to have mumbled on
Samstag, 1. Februar 2003 16:34 Uhr -0500 regarding Re: imapd's hang when
maxchild count is reached:
Date: Fri, 31 Jan 2003 23:25:29 +0100
From: Sebastian Hagedorn <[EMAIL PROTECTED]>
[...]
When th
Date: Fri, 31 Jan 2003 23:25:29 +0100
From: Sebastian Hagedorn <[EMAIL PROTECTED]>
[...]
When the number of impad processes reaches 200, no more processes are
spawned, just as it should be. However, sometimes, not immediately, but
definitely after a while *all* imapd processes will
Hi,
we are currently testing our installation of cyrus-imapd 2.1.11 using a
self-written Perl script that's imitating real use. We intend to contribute
the script when we've cleaned it up a little. Anyway, during our tests we
noticed something strange. In /etc/cyrus.conf we have the line:
ima
21 matches
Mail list logo
