sendmail fails to deliver mail with attachments in /var/spool/mqueue

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

Quoted 4 lines · Jeff V. Merkey

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

If a modern Linux kernel requires high load average defaults, I will stop using Linux.

-NWR

Then perhaps qmail's time has finally come .... If sendmail cannot run on a machine with minimal background loading from a dozen or so FTP clients downloading files, it's clearly sick. BTW. I have another box running qmail, and it doesn't have these problems.

Quoted 5 lines · Jeff V. Merkey

Then perhaps qmail's time has finally come .... If sendmail cannot run on a machine with minimal background loading from a dozen or so FTP clients downloading files, it's clearly sick. BTW. I have another box running qmail, and it doesn't have these problems.

If you have permanently high load average - sure, you need to bump the limits. Always had been that way, nothing to do with the kernel. OTOH, I really don't see WTF are FTP clients giving that kind of LA - unless you've got really thick pipe on a box, that is. If it's a server - WTF are they doing there at all? And if it isn't... Nice connectivity you have there.

I have dual T1 lines going into the box, and I just added a 4-way ADSL circuit as well (4 x 550K). Claus claimed there were TCPIP timeout bugs

Quoted 2 lines · Jeff V. Merkey

I have dual T1 lines going into the box, and I just added a 4-way ADSL circuit as well (4 x 550K). Claus claimed there were TCPIP timeout bugs

Please DON'T quote me wrong. This is getting very annoying. Is that your way to spread rumours and false accusations?

Unless you come up with something constructive, I'm off this "discussion" now.

Then perhaps qmail's time has finally come .... If sendmail cannot run on a machine with minimal background loading from a dozen or so FTP clients downloading files, it's clearly sick. BTW. I have another box running qmail, and it doesn't have these problems.

I have several boxen running sendmail with fair to moderate loading - they even occasionally don't accept mail... and thats good, as it lets the system catch up with its current load. As soon as things stabalize, sendmail again accepts connections - you *do* have MX entries don't you?

Quoted 4 lines · Jeff V. Merkey

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

If a modern Linux kernel requires high load average defaults, I will stop using Linux.

Quoted 4 lines · Jeff V. Merkey

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

If a modern Linux kernel requires high load average defaults, I will stop using Linux.

Followup to:  <[email protected]>
By author:    Neil W Rickert <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 11 lines

Quoted 4 lines · Jeff V. Merkey

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

If a modern Linux kernel requires high load average defaults, I will stop using Linux.

Numerically high load averages aren't inherently a bad thing. There isn't anything bad about a system with a loadavg of 20 if it does what it should in the time you'd expect. However, if your daemons start blocking because they assume this number means badness, than that is the problem, not the loadavg in itself.

average of 10 if there are two processes running? Let's check the man page:

and the three load averages for the system. The load averages are the average number of process ready to
run during the last 1, 5 and 15 minutes. This line
is just like the output of uptime(1).

So: Linux load average on these systems is broken.

-hpa

--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Numerically high load averages aren't inherently a bad thing. There isn't anything bad about a system with a loadavg of 20 if it does what it should in the time you'd expect. However, if your daemons start blocking because they assume this number means badness, than that is the problem, not the loadavg in itself.

Quoted 5 lines · H. Peter Anvin

Numerically high load averages aren't inherently a bad thing. There isn't anything bad about a system with a loadavg of 20 if it does what it should in the time you'd expect. However, if your daemons start blocking because they assume this number means badness, than that is the problem, not the loadavg in itself.

The problem seems to me that the load figure doesn't express what most people seem to expect it to - CPU load.

Well, here's what the sendmail folks **REAL** opinion of Linux is and the way load average is calculated (senders name removed)

[... sendmail person ...]

Ok, here's my blunt answer: Linux sucks. Why does it have a load

Quoted 9 lines

average of 10 if there are two processes running? Let's check the man page:

and the three load averages for the system. The load averages are the average number of process ready to
run during the last 1, 5 and 15 minutes. This line
is just like the output of uptime(1).

So: Linux load average on these systems is broken.

Jeff,

Quoted 15 lines · Jeff V. Merkey

Well, here's what the sendmail folks **REAL** opinion of Linux is and the way load average is calculated (senders name removed)

[... sendmail person ...]

Ok, here's my blunt answer: Linux sucks. Why does it have a load

Quoted 9 lines

average of 10 if there are two processes running? Let's check the man page:

and the three load averages for the system. The load averages are the average number of process ready to
run during the last 1, 5 and 15 minutes. This line
is just like the output of uptime(1).

So: Linux load average on these systems is broken.

Or the documentation is b0rken? This is how the load figure is actually calculated:

/*
* Nr of active tasks - counted in fixed-point numbers */
static unsigned long count_active_tasks(void)

{
        struct task_struct *p;
        unsigned long nr = 0;

        read_lock(&tasklist_lock);
        for_each_task(p) {
                if ((p->state == TASK_RUNNING ||
                     (p->state & TASK_UNINTERRUPTIBLE)))
                        nr += FIXED_1;
        }
        read_unlock(&tasklist_lock);
        return nr;
}

Quoted 5 lines · H. Peter Anvin

Numerically high load averages aren't inherently a bad thing. There isn't anything bad about a system with a loadavg of 20 if it does what it should in the time you'd expect. However, if your daemons start blocking because they assume this number means badness, than that is the problem, not the loadavg in itself.

The problem seems to me that the load figure doesn't express what most people seem to expect it to - CPU load.

Ralf

Quoted 28 lines · Ralf Baechle

Jeff,

Quoted 15 lines · Jeff V. Merkey

Well, here's what the sendmail folks **REAL** opinion of Linux is and the way load average is calculated (senders name removed)

[... sendmail person ...]

Ok, here's my blunt answer: Linux sucks. Why does it have a load

Quoted 9 lines

average of 10 if there are two processes running? Let's check the man page:

and the three load averages for the system. The load averages are the average number of process ready to
run during the last 1, 5 and 15 minutes. This line
is just like the output of uptime(1).

So: Linux load average on these systems is broken.

Or the documentation is b0rken? This is how the load figure is actually calculated:

/*
* Nr of active tasks - counted in fixed-point numbers */
static unsigned long count_active_tasks(void)

Quoted 14 lines

{
        struct task_struct *p;
        unsigned long nr = 0;

        read_lock(&tasklist_lock);
        for_each_task(p) {
                if ((p->state == TASK_RUNNING ||
                     (p->state & TASK_UNINTERRUPTIBLE)))
                        nr += FIXED_1;
        }
        read_unlock(&tasklist_lock);
        return nr;
}

Yes, the documentation is broken. Linus did in fact implement this change because it made most daemons behave significantly better. This ought to include sendmail; it's just that on modern systems the numbers get a little too high for it.

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Quoted 4 lines · Jeff V. Merkey

The problem of dropping connections on 2.4 was related to the O RefuseLA settings. The defaults in the RedHat, Suse, and OpenLinux RPMs are clearly set too low for modern Linux kernels. You may want them cranked up to 100 or something if you want sendmail to always work.

If a modern Linux kernel requires high load average defaults, I will stop using Linux.

Yes, the documentation is broken. Linus did in fact implement this

Quoted 1 line · H. Peter Anvin

Yes, the documentation is broken. Linus did in fact implement this

Well, also the implementation could be improved IMHO, think when we have one houndred of tasks sleeping in uninterruptible mode because the nfs server is down for maintenance. They're no loading the machine at all for half an hour even while the load is 100. For sure the fix is not to account only runnable tasks though, since when the machine trashes into swap all tasks blocks and they almost never runs but in such a case we must report that all tasks are trying to make progress and that they're effectively loading the machine even if they sleeps in uninterruptible mode all the time. I'd prefer a generic approch but also a magic for some case like nfs server down could take care of that.

Andrea