Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

preventing forking/using of daemon

9 views
Skip to first unread message

Walter Haidinger

unread,
Aug 16, 1998, 3:00:00 AM8/16/98
to
Hi!

If you remember my previous post (seperate queueing of incoming/outgoing
mail) you may remember that I had problems with many concurrent sendmails
causing a heavy system load.

Now, queuing does not solve my problem. Instead of many sendmails processes
delivering, I have as many queuing. Therefore load averaging is also of no
use here. Queuing is faster, but still no solution on a 486.

Here is what I really need:
Prevent sendmail from forking itself, i.e. not to use the sendmail daemon.

To clearify things a bit, here is my setup:
Sendmail is started in daemon mode (options: -bd -om) from /etc/rc. Local
mail delivery is fine, as is outgoing mail.
For each *incoming* mail, sendmail is called by procmail. Each sendmail
called sees the daemon running and immediately forks itself (correct?).
FYI: All those concurrent sendmails have ppid 1. Hhm.

Anyways, each sendmail run by procmail should *not* fork itself, deliver
the mail and exit. Then, procmail would continue to process the next
message. That way, only *one* sendmail process (of procmail) would be running.
The initial sendmail daemon should continue to run.

sendmail is run from .procmailrc by piping the message to sendmail:
| sendmail <options> user@host

I'd appreciate any hints. Thanks!

Regards, Walter


--
Haidinger Walter <walter.h...@gmx.net>
Student of Electrical Engineering, University of Technology, Vienna, Austria
Address: Brunnerstr.6, A-3108 St.P"olten, Austria. Tel.: +43-2742-257191

Per Hedeland

unread,
Aug 18, 1998, 3:00:00 AM8/18/98
to
In article <ExsxG...@pgv.at> Walter Haidinger

<walter.h...@gmx.net> writes:
>For each *incoming* mail, sendmail is called by procmail. Each sendmail
>called sees the daemon running and immediately forks itself (correct?).

No, sendmail forks for delivery, but that has nothing to do with the
daemon running, it's just its default delivery mode ("background"). You
can prevent that fork by calling sendmail with -odi ("interactive"
delivery mode).

>sendmail is run from .procmailrc by piping the message to sendmail:
>| sendmail <options> user@host

You may want to use the 'w' or 'W' flag on the procmail recipe too - I
believe procmail won't wait for the program to finish otherwise, i.e. it
will exit as soon as it has fed the message to sendmail.

--Per Hedeland
p...@erix.ericsson.se

Walter Haidinger

unread,
Aug 18, 1998, 3:00:00 AM8/18/98
to
Thanks for you reply, Per!

Per Hedeland <p...@erix.ericsson.se> wrote:
> You may want to use the 'w' or 'W' flag on the procmail recipe too - I
> believe procmail won't wait for the program to finish otherwise, i.e. it
> will exit as soon as it has fed the message to sendmail.

On the procmail mailinglist, I got the following hint:
If procmail is the local mailer actually called by sendmail and if the user
'someuser' really exists, one could use the following procmail recipe

:0w:
* <conditions>
| procmail -d someuser@localhost

instead of '! someuser@localhost'.
This elimiates the overhead of sendmail alltogether, reducing system-load
dramatically. That is, for me on my 486.

Regards, Walter

PS: I know this isn't quite a sendmail topic, but perhaps someone other
would like to know about a solution. So, I hope noboby of c.m.sendmail
is too upset...

0 new messages