Milter-greylist

We are running two v490 sun boxes with 8 and everything is running fine 
with two standalone milter-greylist running but when we run peering one 
server or the other drops milter-greylist. greylist runs for less than 
a day before it dies. We are seeing 300,000 to 600,000 messages a day 
across both servers. Is there any fixes in 3.1 for peering? How do I 
get help with this?

On Fri, 02 Mar 2007 17:35:55 -0000 Brian Akey <bakey@...> wrote:

> We are running two v490 sun boxes with 8 and everything is running fine 
> with two standalone milter-greylist running but when we run peering one 
> server or the other drops milter-greylist. greylist runs for less than 
> a day before it dies. We are seeing 300,000 to 600,000 messages a day 
> across both servers. Is there any fixes in 3.1 for peering? How do I 
> get help with this?

Please run milter-greylist under debugger and post backtrace here when it crashes.

Regards,
Nerijus

Brian Akey <bakey@...> wrote:

> We are running two v490 sun boxes with 8 and everything is running fine
> with two standalone milter-greylist running but when we run peering one
> server or the other drops milter-greylist. greylist runs for less than
> a day before it dies. We are seeing 300,000 to 600,000 messages a day
> across both servers. Is there any fixes in 3.1 for peering? How do I 
> get help with this?

A usual problem with Solaris boxen is the stream limit at 256 for 32 bit
applications. Is milter-greylist built as a 32 bit binary?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

I think we used gcc so it might be. I'll check. So it would work better compiled as 64 bit or would it run better on a 32bit linux server?

-----Original Message-----
From: milter-greylist@yahoogroups.com on behalf of manu@netbsd.org
Sent: Fri 3/2/2007 1:46 PM
To: milter-greylist@yahoogroups.com
Subject: Re: [milter-greylist] peering problems on sun 8
 
Brian Akey <bakey@memphis.edu> wrote:

> We are running two v490 sun boxes with 8 and everything is running fine
> with two standalone milter-greylist running but when we run peering one
> server or the other drops milter-greylist. greylist runs for less than
> a day before it dies. We are seeing 300,000 to 600,000 messages a day
> across both servers. Is there any fixes in 3.1 for peering? How do I 
> get help with this?

A usual problem with Solaris boxen is the stream limit at 256 for 32 bit
applications. Is milter-greylist built as a 32 bit binary?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org

<bakey@...> wrote:

> I think we used gcc so it might be. I'll check. So it would work better
> compiled as 64 bit or would it run better on a 32bit linux server?

According to user reports, both would be fine. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

An.H.Nguyen <AnNguyen251@...> wrote:

> I'm running the latest version 3.1.6 and discovered that peering is no
> Ilonger working. t used to work with 3.0. How do I add it back to 3.1.6?

How does it fail? Do you have an error reported?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On Mon, Mar 05, 2007 at 10:55:21PM -0800, aNguyen wrote:
> It does not give me any error. It simply does not synchronize to its peer and there's no mxsync in the message log. How do I find error?

First, run with -Dv
Then, try tcpdump to see if there are connexion attempts or not. Try to
telnet on port 5252 to see if the daemon answers to MX sync requests.

-- 
Emmanuel Dreyfus
manu@...

Hi,

I try to find anything about this in the list archive, but the only
thing that I found was some old posts from 2005 about case (in)sensitive
in the whitelisting syntax of greylist.conf. (Same result then I search
ChangeLog file of milter-greylist 3.0)

I'm (still) running milter-greylist 2.1.5, and it seems to be so that
the tuples (from/rcpt addresses) are case sensitive. Why do
milter-greylist has that?

193.42.254.15   <kbp@...>  <tommy.jeppesen@...>
1173255038 # 2007-03-07 09:10:38
193.42.254.15   <kbp@...>  <Tommy.Jeppesen@...>
1173255384 # 2007-03-07 09:16:24

A con is that both those mails need to be resent before the both tuples
are autowhitelisted. Wouldn't it be good if (at least) the rcpt address
was case insensitive?

/P

manu@... wrote:
 > A usual problem with Solaris boxen is the stream limit at 256 for 32 bit
 > applications. Is milter-greylist built as a 32 bit binary?

You don't need to make a 64bit binary in order to
get around that limit.  On recent Solaris versions
you can increase the current limit using ulimit on
the command line, or setrlimit() from within a
program (which is recommended if a program needs
that many).  In Solaris 10 you can use resource
limits, see the resource_controls(5) manual page.

In old Solaris releases you can increase the limits
globally via /etc/system.  For example, add these
lines:

set rlim_fd_max=8192
set rlim_fd_cur=1024

It sets the maximum ("hard") limit to 8192 and the
current ("soft") limit to 1024.  You need to reboot
for the change to take effect, because the kernel
reads /etc/system only upon reboot.  (Well, you
can also change the values with adb on a running
system, but that's somewhat dangerous.)

Furthermore, the application (milter-greylist) must
be compiled with a larger FD_SETSIZE if you need more
than 1024 file descriptors (the default is 1024 for
32bit apps).  It might be useful to add a configure
option for that to milter-greylist.

Maybe that hint should be added to milter-greylist's
README, because many Solaris users seem to stumble
across that problem.

Best regards
   Oliver


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Python is an experiment in how much freedom programmers need.
Too much freedom and nobody can read another's code; too little
and expressiveness is endangered."
        -- Guido van Rossum

On Wed, Mar 07, 2007 at 03:23:46PM +0100, Oliver Fromme wrote:
> Maybe that hint should be added to milter-greylist's
> README, because many Solaris users seem to stumble
> across that problem.

Sure, can you send a patch for that?

-- 
Emmanuel Dreyfus
manu@...

<fredrik.pettai@...> wrote:

> 193.42.254.15   <kbp@...>  <tommy.jeppesen@...>
> 1173255038 # 2007-03-07 09:10:38
> 193.42.254.15   <kbp@...>  <Tommy.Jeppesen@...>
> 1173255384 # 2007-03-07 09:16:24
> 
> A con is that both those mails need to be resent before the both tuples
> are autowhitelisted. Wouldn't it be good if (at least) the rcpt address
> was case insensitive?

I don't know: what real MTA will change the case between two delivery
attempts of the same message? In what situation did you experienced the
situation above?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

An.H.Nguyen <AnNguyen251@...> wrote:

> Through my tests, it is confirmed that tcpdump does not show any sync
> activity between the peers. But telneting in port 5252 does work
> correctly. I think version 3.1.6 code does not turn on sync. Please let me
> know which source file to check for enabling sync then I'll recompile from
> source code. I swichted back to version 3.0 and sync works fine, but 3.0
> does not dump the database when milter-greylist is killed and restarted.

Running with -Dv, you have no error message?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

An.H.Nguyen <AnNguyen251@...> wrote:

> When running with -Dv, there are too many messages throwing up to the
> terminal which shows all greylist/whitelist activities. I am unable to
> see any error message.

Redirect the flow to a file, run long enough to reach the situation
where a sync should occur (this will happen if a greylist entry is
added), then stop it and send me the file.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

>I don't know: what real MTA will change the case between two delivery
>attempts of the same message? In what situation did you experienced the
>situation above?

I don't think those entries are for the same mail. I think those are
different mails but sent to the same rcpt, from the same user, but with
different (case sensitive) addresses to the rcpt. (For instance, one
message may be a reply on a sent mail from the rcpt, and the other may
be written manually by the user.)

fredrik.pettai@... wrote:
 > 
 > > I don't know: what real MTA will change the case between two delivery
 > > attempts of the same message? In what situation did you experienced the
 > > situation above?
 > 
 > I don't think those entries are for the same mail. I think those are
 > different mails but sent to the same rcpt, from the same user, but with
 > different (case sensitive) addresses to the rcpt. (For instance, one
 > message may be a reply on a sent mail from the rcpt, and the other may
 > be written manually by the user.)

Unfortunately, it isn't that simple.  According to RFC2822,
only the domain part is case-insensitive.  So the addresses
bugs@... and bugs@... must be assumed to be
identical (does milter-greylist do that?).  However, the
local part (i.e. to the left of the "@" sign) is interpreted
locally, and it is undefined whether that is case-sensitive
or not.

So, in theory, that means that tom@..., Tom@... and
TOM@... could be the same person, but it is also very
possible that it is three different persons.

Well, it might be possible to add a configuration switch to
milter-greylist so the admin can tell it whether local
domains use case-sensitive mail names or not.  But there is
no way it can know that for remote domains.  If in doubt,
mail names should always be assumed to be case-sensitive,
which is the current behaviour.

A similar issue arises when aliases come into play.  For
example, assume someone sends mail to root@..., and
then also sends a mail to admin@... or webmaster@ or
postmaster@ (happens quite often).  _All_ of those mails
will be greylisted and delayed, even if they are all
aliased to the same person (milter-greylist has no way
to know that).  I think that the behaviour makes sense
and is not a bug.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke

On Wed, Mar 07, 2007 at 03:23:46PM +0100, Oliver Fromme wrote:
>  > A usual problem with Solaris boxen is the stream limit at 256 for 32 bit
>  > applications. Is milter-greylist built as a 32 bit binary?
> 
> You don't need to make a 64bit binary in order to
> get around that limit.  On recent Solaris versions
> you can increase the current limit using ulimit on
> the command line, or setrlimit() from within a
> program (which is recommended if a program needs
> that many). 

The problem is or at least was that "milter-greylist" want to use fdopen()
to write the database file. And Solaris' standard I/O implementation only
supports file descriptors < 256 for 32 bit programs.

	Kind regards

-- 
Matthias Scheler                                  http://zhadum.org.uk/

Matthias Scheler <tron@...> wrote:

> The problem is or at least was that "milter-greylist" want to use fdopen()
> to write the database file. And Solaris' standard I/O implementation only
> supports file descriptors < 256 for 32 bit programs.

Pehaps the code could be modified to work around this limitation? If
fopen also limited?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On 3/8/07, manu@... <manu@...> wrote:
> Matthias Scheler <tron@...> wrote:
>
>  > The problem is or at least was that "milter-greylist" want to use fdopen()
>  > to write the database file. And Solaris' standard I/O implementation only
>  > supports file descriptors < 256 for 32 bit programs.
>
>  Pehaps the code could be modified to work around this limitation? If
>  fopen also limited?

It would be great if you who know the code could try to solve it that
way. I have run into this too and I could not solve it by any
configuring, I think Matthias is right that it is a limitation.

-- 
/peter

On Thu, Mar 08, 2007 at 02:04:15PM +0100, shuttlebox wrote:
> It would be great if you who know the code could try to solve it that
> way. I have run into this too and I could not solve it by any
> configuring, I think Matthias is right that it is a limitation.

Here is the story: We need to safely open a temporary file as a FILE *.
I use mkstemp, followed by fdopen on the file descriptor.

What alternative do I have?

-- 
Emmanuel Dreyfus
manu@...

Matthias Scheler wrote:
 > Oliver Fromme wrote:
 > > [...]
 > > > A usual problem with Solaris boxen is the stream limit at 256 for 32 bit
 > > > applications. Is milter-greylist built as a 32 bit binary?
 > > 
 > > You don't need to make a 64bit binary in order to
 > > get around that limit.  On recent Solaris versions
 > > you can increase the current limit using ulimit on
 > > the command line, or setrlimit() from within a
 > > program (which is recommended if a program needs
 > > that many). 
 > 
 > The problem is or at least was that "milter-greylist" want to use fdopen()
 > to write the database file. And Solaris' standard I/O implementation only
 > supports file descriptors < 256 for 32 bit programs.

That's true.  I didn't realize that it was using stdio
functions (I only thought of the network sockets).

Well, there are three solutions:

 - Do not use stdio functions (i.e. no functions that use
   FILE*), but instead use open(2), write(2) etc.  However,
   that might be inconvenient and/or inefficient, depending
   on the kind of use.

 - Use SFIO from AT&T, which is a replacement for stdio and
   does not have a restriction on the number of streams:
   http://www.research.att.com/~gsf/download/ref/sfio/sfio.html
   However, requiring such a third-party library for milter-
   greylist is probably awkward, and I'm not sure about the
   licensing issues.

 - Best solution:  Reserve a low-numbered file descriptor
   at the start of the program.  For example, you can call
      low_fd = open("/dev/null", O_RDWR);
   right at the start of the program, so it will probably
   get FD 3 (because only FD 0, 1, and 2 are used for stdin,
   stdout and stderr).  After daemonifocation you might
   even get FD 0, because stdin/out/err are usually closed
   when you become a daemon. 

   Then just keep that FD ("low_fd" in the example above)
   around for later use.  Then, if you need a FILE* with
   a low numbered FD (so you can use stdio functions), do
   this:

    + Open the file normally with open(2).  That will
      give you a high-numbered FD:
         high_fd = open("greylist.db", O_RDWR);
      Of course, you can also use mkstemp() which calls
      open() internally and returns such an FD as well:
         high_fd = mkstemp("greylist.db.XXXXXX");

    + Use dup2() to duplicate the descriptor to the low-
      numbered FD that you reserved at the beginning:
         error = dup2(high_fd, low_fd)
      If low_fd is still open, it is closed first, then
      it is associated with the same file as high_fd.
      You can close high_fd now; it's not needed anymore
      so you can free the FD:
         close(high_fd);
      Now you can use fdopen() to retrieve a FILE*
      pointer for low_fd, and use stdio functions with
      that FILE* normally:
         myfile = fdopen(low_fd, "r+");

    + When you're done with the file, do _not_ close()
      or fclose() low_fd!  That would free the descriptor,
      so it might get re-used by somethign else (e.g. for
      a network socket), so you lose your low-numbered FD.
      Instead, fflush() the FILE*, then open /dev/null
      again and dup2 it back to your low_fd, so the file
      is closed but you still have the FD:
         error = fflush(myfile);
         high_fd = open("/dev/null", O_RDWR);
         error = dup2(high_fd, low_fd); /* close db file */

   No, I'm not going to submit a patch.  I guess it's easy
   enough for somebody else, given the above explanations.
   :-)

Best regards
   Oliver   

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
        -- Chris Torek

>     + When you're done with the file, do _not_ close()
>       or fclose() low_fd!  That would free the descriptor,
>       so it might get re-used by somethign else (e.g. for
>       a network socket), so you lose your low-numbered FD.
>       Instead, fflush() the FILE*, then open /dev/null
>       again and dup2 it back to your low_fd, so the file
>       is closed but you still have the FD:
>          error = fflush(myfile);
>          high_fd = open("/dev/null", O_RDWR);
>          error = dup2(high_fd, low_fd); /* close db file */
> 

I think it is not going to clean-up sufficiently the data structures
used by stdio library. The FILE* is still a valid file pointer some
should clean-it up, (buffers, etc). On the other hand you cannot simply
fclose it even after some dup2() manipulation, since the internal 
file descriptor value in FILE* is still low_fd.
It looks like some function is missing which would do the task, something like
fdclose(). It should clean up all the stdio related resources, but do not close
the file descriptor at the end. It is the symmetric counterpart of the fdopen().
Did anybody thought about this before?
YES: http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/011028.html
I have the impression that without this function the problem cannot be solved cleanly/portably.

attila.bruncsak@... wrote:
 > 
 > >     + When you're done with the file, do _not_ close()
 > >       or fclose() low_fd!  That would free the descriptor,
 > >       so it might get re-used by somethign else (e.g. for
 > >       a network socket), so you lose your low-numbered FD.
 > >       Instead, fflush() the FILE*, then open /dev/null
 > >       again and dup2 it back to your low_fd, so the file
 > >       is closed but you still have the FD:
 > >          error = fflush(myfile);
 > >          high_fd = open("/dev/null", O_RDWR);
 > >          error = dup2(high_fd, low_fd); /* close db file */
 > 
 > I think it is not going to clean-up sufficiently the data structures
 > used by stdio library. The FILE* is still a valid file pointer some
 > should clean-it up, (buffers, etc).

Right, I didn't thinmk about that.  However ...

 > http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/011028.html

That message contains a workaround.  If calls fclose() on
the FILE*, then immediately uses dup2() to re-allocate the
file descriptor low_fd.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."

>  > 
> http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/0
> 11028.html
> 
> That message contains a workaround.  If calls fclose() on
> the FILE*, then immediately uses dup2() to re-allocate the
> file descriptor low_fd.
> 

It is not guaranteed in a multithreaded program working reliably.

On Thu, 8 Mar 2007 10:22:26 +0100 (CET) Oliver Fromme <olli@...> wrote:

> So, in theory, that means that tom@..., Tom@... and
> TOM@... could be the same person, but it is also very
> possible that it is three different persons.

Very?:) I know that local part could be case sensitive, but I
never saw it in practice. Did anyone?

Regards,
Nerijus

attila.bruncsak@... wrote:
 > 
 > > >  
 > > http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/0
 > > 11028.html
 > >  
 > > That message contains a workaround.  If calls fclose() on
 > > the FILE*, then immediately uses dup2() to re-allocate the
 > > file descriptor low_fd.
 > >  
 > 
 > It is not guaranteed in a multithreaded program working reliably.

Come on, multithreaded programming isn't voodoo magic.  :-)
You can easily make the guarantee that there is no race
condition by properly programming, e.g. using a semaphore
or mutex.  If you're doing threaded programming, then you
should very well know what you're doing anyway.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Perl will consistently give you what you want,
unless what you want is consistency."
        -- Larry Wall

Nerijus Baliunas wrote:
 > Oliver Fromme wrote:
 > 
 > > So, in theory, that means that tom@..., Tom@... and
 > > TOM@... could be the same person, but it is also very
 > > possible that it is three different persons.
 > 
 > Very?:) I know that local part could be case sensitive, but I
 > never saw it in practice. Did anyone?

Yes, I've seen a box where the Admin@ alias contained more
people than the admin@ alias (the latter was a subset of
the former).

Apart from that:  It is my opinion that milter-greylist
should try to be as RFC-compliant as possible, in order to
avoid any potential interoperability problems and pitfalls.
Parsing addresses conforming with RFC2822 correctly is a
very important aspect of that, I think.

By the way, Eric Allman himself strongly suggests that
mail names must never be "fuzzy", but must be exactly and
strictly matched.

Best regards
   Oliver


-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"It combines all the worst aspects of C and Lisp:  a billion different
sublanguages in one monolithic executable.  It combines the power of C
with the readability of PostScript."
        -- Jamie Zawinski, when asked: "What's wrong with perl?"

>  > >   
>  > > http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/0
>  > > 11028.html
>  > >  
>  > > That message contains a workaround.  If calls fclose() on
>  > > the FILE*, then immediately uses dup2() to re-allocate the
>  > > file descriptor low_fd.
>  > >  
>  > 
>  > It is not guaranteed in a multithreaded program working reliably.
> 
> Come on, multithreaded programming isn't voodoo magic.  :-)
> You can easily make the guarantee that there is no race
> condition by properly programming, e.g. using a semaphore
> or mutex.  If you're doing threaded programming, then you
> should very well know what you're doing anyway.
> 

You are absolutely right as any good politician giving generic statements. Please stay on the Earth.
I did not thought that I have to give more details, here it is:
If you want to use fclose(); dup2() sequence, you have to protect all the system calls in your program which leads to file descriptor allocation in all the threads. Otherwise the kernel will allocate this low file descriptor to other thread, if your current thread is pre-empted in the middle of this critical section.
For example you have to modify the libmilter blocking the execution of accept() on the milter socket while your dump thread is in the above sequence. Theoretically possible, practically impossible to implement.

> Oliver Fromme wrote:
>
>Apart from that: It is my opinion that milter-greylist
>should try to be as RFC-compliant as possible, in order to
>avoid any potential interoperability problems and pitfalls.
>Parsing addresses conforming with RFC2822 correctly is a
>very important aspect of that, I think.

Yes, I'd have to agree with that...

Thanks for the info,
/P

attila.bruncsak@... wrote:
 > For example you have to modify the libmilter blocking the execution
 > of accept() on the milter socket while your dump thread is in the
 > above sequence. Theoretically possible, practically impossible to
 > implement.

Yes, true, and we all know that libmilter sucks.  :-(

So, there are still the other two possibilities that I
mentioned:  Avoid stdio for writing the database dump,
or use SFIO on Solaris.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The last good thing written in C was
Franz Schubert's Symphony number 9."
        -- Erwin Dieterich

On 3/9/07, Oliver Fromme <olli@...> wrote:
>  attila.bruncsak@... wrote:
>   > For example you have to modify the libmilter blocking the execution
>   > of accept() on the milter socket while your dump thread is in the
>   > above sequence. Theoretically possible, practically impossible to
>   > implement.
>
>  Yes, true, and we all know that libmilter sucks.  :-(
>
>  So, there are still the other two possibilities that I
>  mentioned:  Avoid stdio for writing the database dump,
>  or use SFIO on Solaris.

Is there a possibility for a patch?

-- 
/peter