Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 11:38:31AM -0800, J Sloan wrote: > "Jeff V. Merkey" wrote: > > It is good that you raised the issue - THanks Jeff > > Cheers, > > jjs > > - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 11:38:31AM -0800, J Sloan wrote: "Jeff V. Merkey" wrote: It is good that you raised the issue - THanks Jeff Cheers, jjs - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, 11 Nov 2000, Jeff V. Merkey wrote: >On Sat, Nov 11, 2000 at 01:40:42PM +, Henning P. Schmiedehausen wrote: >> [EMAIL PROTECTED] (Jeff V. Merkey) writes: >> >> >> >We got to the bottom of the sendmail problem. The line: >> >> > -O QueueLA=20 >> >> >and >> >> > -O RefuseLA=18 >> >> >Need to be cranked up in sendmail.cf to something high since the >> >background VM on a very busy Linux box seems to exceed this which causes >> >large emails to get stuck in the /var/spool/mqueue directory for long >> >periods of time. Since vger is getting hammered with FTP all the time, >> >and is rarely idle. This also explains what Richard was seeing with VM >> >thrashing in a box with low memory. >> >> So what? This is written in the documentation of the program? You do read >> documentation, do you? >> >> >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. >> >> These settings are for single user / small user numbers boxes. >> >> If you're using an out of the vendor box distribution configuration >> for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your >> consultant is an idiot. >> >> Regards >> Henning > > >I guess all customers are idiots then, since about 100+ people who were >using our release downloaded it, and had these problems with sendmail. This >disconnect of yours is about what I would expect from someone in a University. >Some of us don't have the luxury of being able to pontificate in a Univ >environment -- we have to make a living from Linux -- and provide payroll >for the people on this list who actually do the core work on Linux. > >If there were not a commercialization effort around Linux, it would still >be unknown, like TMOK or a lot of other kernels sitting in universities >somewhere not being deployed. It's the commercialization effort that made >Linux a household word. NT and NetWare servers don't stop forwarding >emails when the load average gets too high -- they just work out of the >box, and hopefully, no so will Linux (our distribution does now since >this problem in fixed). > >Now we know that sendmail has problems on Linux based on the this load >average interpretation, which we would not have known if someone had >not raised the issue. This is not a problem with sendmail on Linux. The same thing will happen on ANY uni-processor system (multi-processor too, but not as severe). I run sendmail on an SGI Indy (yes, that no-longer-manufactured thing) and it is necessary to set the load average on it to 75 or so. As high as 150 is not unreasonable either. This system handles 10's of thousands of mail messages per day. This is only a matter of tuning sendmail to do what you want, when you want. It is also reasonably well documented in the sendmail distribution. You do have to monitor the system to determine what "high" really is. In the case of the NT servers, I have seen them choke (and crash) since they DON'T seem to throttle very well. BTW, After I read the sendmail documentation, and observed the system for a while, I decided to count the sendmail "loadaverage" as really being the average number of simultaneous connections (sendmail processes/threads). This leads to the choice of "how many do I want active, and how many do I want to suspended, and when do I want to refuse connection". THEN I add the number of other active processes to the proposed limits. -- - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"Jeff V. Merkey" wrote: > NT and NetWare servers don't stop forwarding > emails when the load average gets too high -- they just work out of the > box, and hopefully, no so will Linux (our distribution does now since > this problem in fixed). Don't get me started on nt - saying it "just works" is a sign of genuine naivete - You could say nt "usually works, except for when it's down". Your sendmail issue with Linux was merely a tunable parameter, while the nt problems go much deeper, and nt often requires regular reboots in order to carry on. > Now we know that sendmail has problems on Linux based on the this load > average interpretation, which we would not have known if someone had > not raised the issue. It is good that you raised the issue - Cheers, jjs - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Jeff V. Merkey) writes: >I guess all customers are idiots then, since about 100+ people who were >using our release downloaded it, and had these problems with sendmail. This >disconnect of yours is about what I would expect from someone in a University. >Some of us don't have the luxury of being able to pontificate in a Univ >environment -- we have to make a living from Linux -- and provide payroll >for the people on this list who actually do the core work on Linux. I earn a living with building and deploying Internet system on a variety of (Unix-based) platforms. Each one has its quirks and to build successful servers, you have to know about them. I never ever deployed a sendmail.cf as it came from the vendor or the source package. I adjust these config files to the customers' need. [...] >somewhere not being deployed. It's the commercialization effort that made >Linux a household word. NT and NetWare servers don't stop forwarding THERE IS NO SUCH EFFORT. This list is not your general-purpose Linux support list. If you need support for a distribution, get it from the vendor. If you make a distribution, that deploys a software, give this support or buy it from people who _know_ and sell it to your customers. But this list is not for your "I don't have a clue" efforts. Deploying a distribution is major grunt work that most customers will never see. I e.g. deploy a highly customized version of RedHat on the servers that I build. Most of my customers ask a second and a third time why I don't simply deploy the distribution out of the box like all the consultants that they had before. They stop asking when their old boxes are cracked open or fail under load and mine doesn't. If you deploy a general purpose distribution or OS for a very special application, then you simply use the wrong tool. >emails when the load average gets too high -- they just work out of the >box, and hopefully, no so will Linux (our distribution does now since >this problem in fixed). Your distribution will simply have "RefuseLA" and "QueueLA" higher than the sendmail defaults. This is not the solution to your problem but moves it simply to a different point. You simply don't understand, that a cluster mail system that handles 20,000,000 mailboxes and 200,000,000 mails per day must be configured different than the mail system on a high traffic web server, that simply sends out two mails per day from the logfile rotation. Both machines may have a load average way beyond a desktop system that peaks at 0.05 on normal usage. >Now we know that sendmail has problems on Linux based on the this load >average interpretation, which we would not have known if someone had >not raised the issue. Linux has no problem. Some sites that run Linux have a problem because they're misconfigured. And if you ship a distribution but want to load off the support for this distribution on Linux-Kernel, you're definitely in for a surprise. TANSTAAFL, you know. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 01:40:42PM +, Henning P. Schmiedehausen wrote: > [EMAIL PROTECTED] (Jeff V. Merkey) writes: > > > >We got to the bottom of the sendmail problem. The line: > > > -O QueueLA=20 > > >and > > > -O RefuseLA=18 > > >Need to be cranked up in sendmail.cf to something high since the > >background VM on a very busy Linux box seems to exceed this which causes > >large emails to get stuck in the /var/spool/mqueue directory for long > >periods of time. Since vger is getting hammered with FTP all the time, > >and is rarely idle. This also explains what Richard was seeing with VM > >thrashing in a box with low memory. > > So what? This is written in the documentation of the program? You do read > documentation, do you? > > >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. > > These settings are for single user / small user numbers boxes. > > If you're using an out of the vendor box distribution configuration > for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your > consultant is an idiot. > > Regards > Henning I guess all customers are idiots then, since about 100+ people who were using our release downloaded it, and had these problems with sendmail. This disconnect of yours is about what I would expect from someone in a University. Some of us don't have the luxury of being able to pontificate in a Univ environment -- we have to make a living from Linux -- and provide payroll for the people on this list who actually do the core work on Linux. If there were not a commercialization effort around Linux, it would still be unknown, like TMOK or a lot of other kernels sitting in universities somewhere not being deployed. It's the commercialization effort that made Linux a household word. NT and NetWare servers don't stop forwarding emails when the load average gets too high -- they just work out of the box, and hopefully, no so will Linux (our distribution does now since this problem in fixed). Now we know that sendmail has problems on Linux based on the this load average interpretation, which we would not have known if someone had not raised the issue. Jeff > > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] > > Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] > D-91054 Buckenhof Fax.: 09131 / 50654-20 > - > 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/ - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 12:54:20PM +0100, Andrea Arcangeli wrote: > On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote: > > 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. I've actualy seen this with a bunch of NFS clients idle, and sendmail stops delivering email until the load average drops. What's of more concern is the intense VM implementation Rik has done -- it's a great piece of work, but it appears when heavy swapping is going on, sendmail also stops delivering email as well. 8) Jeff > > Andrea - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Richard A Nelson) writes: >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? % dig timpanogas.com mx [...] timpanogas.com. 1D IN MX10 mail.timpanogas.com. No. He _is_ clueless with a big mouth as the regular readers of LKM already know. "and it's all either the fault of other people or the kernel". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Jeff V. Merkey) writes: >We got to the bottom of the sendmail problem. The line: > -O QueueLA=20 >and > -O RefuseLA=18 >Need to be cranked up in sendmail.cf to something high since the >background VM on a very busy Linux box seems to exceed this which causes >large emails to get stuck in the /var/spool/mqueue directory for long >periods of time. Since vger is getting hammered with FTP all the time, >and is rarely idle. This also explains what Richard was seeing with VM >thrashing in a box with low memory. So what? This is written in the documentation of the program? You do read documentation, do you? >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. These settings are for single user / small user numbers boxes. If you're using an out of the vendor box distribution configuration for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your consultant is an idiot. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote: > 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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Jeff V. Merkey) writes: We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. So what? This is written in the documentation of the program? You do read documentation, do you? 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. These settings are for single user / small user numbers boxes. If you're using an out of the vendor box distribution configuration for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your consultant is an idiot. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Richard A Nelson) writes: 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? % dig timpanogas.com mx [...] timpanogas.com. 1D IN MX10 mail.timpanogas.com. No. He _is_ clueless with a big mouth as the regular readers of LKM already know. "and it's all either the fault of other people or the kernel". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 12:54:20PM +0100, Andrea Arcangeli wrote: On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote: 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. I've actualy seen this with a bunch of NFS clients idle, and sendmail stops delivering email until the load average drops. What's of more concern is the intense VM implementation Rik has done -- it's a great piece of work, but it appears when heavy swapping is going on, sendmail also stops delivering email as well. 8) Jeff Andrea - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, Nov 11, 2000 at 01:40:42PM +, Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] (Jeff V. Merkey) writes: We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. So what? This is written in the documentation of the program? You do read documentation, do you? 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. These settings are for single user / small user numbers boxes. If you're using an out of the vendor box distribution configuration for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your consultant is an idiot. Regards Henning I guess all customers are idiots then, since about 100+ people who were using our release downloaded it, and had these problems with sendmail. This disconnect of yours is about what I would expect from someone in a University. Some of us don't have the luxury of being able to pontificate in a Univ environment -- we have to make a living from Linux -- and provide payroll for the people on this list who actually do the core work on Linux. If there were not a commercialization effort around Linux, it would still be unknown, like TMOK or a lot of other kernels sitting in universities somewhere not being deployed. It's the commercialization effort that made Linux a household word. NT and NetWare servers don't stop forwarding emails when the load average gets too high -- they just work out of the box, and hopefully, no so will Linux (our distribution does now since this problem in fixed). Now we know that sendmail has problems on Linux based on the this load average interpretation, which we would not have known if someone had not raised the issue. Jeff -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/ - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[EMAIL PROTECTED] (Jeff V. Merkey) writes: I guess all customers are idiots then, since about 100+ people who were using our release downloaded it, and had these problems with sendmail. This disconnect of yours is about what I would expect from someone in a University. Some of us don't have the luxury of being able to pontificate in a Univ environment -- we have to make a living from Linux -- and provide payroll for the people on this list who actually do the core work on Linux. I earn a living with building and deploying Internet system on a variety of (Unix-based) platforms. Each one has its quirks and to build successful servers, you have to know about them. I never ever deployed a sendmail.cf as it came from the vendor or the source package. I adjust these config files to the customers' need. [...] somewhere not being deployed. It's the commercialization effort that made Linux a household word. NT and NetWare servers don't stop forwarding THERE IS NO SUCH EFFORT. This list is not your general-purpose Linux support list. If you need support for a distribution, get it from the vendor. If you make a distribution, that deploys a software, give this support or buy it from people who _know_ and sell it to your customers. But this list is not for your "I don't have a clue" efforts. Deploying a distribution is major grunt work that most customers will never see. I e.g. deploy a highly customized version of RedHat on the servers that I build. Most of my customers ask a second and a third time why I don't simply deploy the distribution out of the box like all the consultants that they had before. They stop asking when their old boxes are cracked open or fail under load and mine doesn't. If you deploy a general purpose distribution or OS for a very special application, then you simply use the wrong tool. emails when the load average gets too high -- they just work out of the box, and hopefully, no so will Linux (our distribution does now since this problem in fixed). Your distribution will simply have "RefuseLA" and "QueueLA" higher than the sendmail defaults. This is not the solution to your problem but moves it simply to a different point. You simply don't understand, that a cluster mail system that handles 20,000,000 mailboxes and 200,000,000 mails per day must be configured different than the mail system on a high traffic web server, that simply sends out two mails per day from the logfile rotation. Both machines may have a load average way beyond a desktop system that peaks at 0.05 on normal usage. Now we know that sendmail has problems on Linux based on the this load average interpretation, which we would not have known if someone had not raised the issue. Linux has no problem. Some sites that run Linux have a problem because they're misconfigured. And if you ship a distribution but want to load off the support for this distribution on Linux-Kernel, you're definitely in for a surprise. TANSTAAFL, you know. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"Jeff V. Merkey" wrote: NT and NetWare servers don't stop forwarding emails when the load average gets too high -- they just work out of the box, and hopefully, no so will Linux (our distribution does now since this problem in fixed). Don't get me started on nt - saying it "just works" is a sign of genuine naivete - You could say nt "usually works, except for when it's down". Your sendmail issue with Linux was merely a tunable parameter, while the nt problems go much deeper, and nt often requires regular reboots in order to carry on. Now we know that sendmail has problems on Linux based on the this load average interpretation, which we would not have known if someone had not raised the issue. It is good that you raised the issue - Cheers, jjs - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Sat, 11 Nov 2000, Jeff V. Merkey wrote: On Sat, Nov 11, 2000 at 01:40:42PM +, Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] (Jeff V. Merkey) writes: We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. So what? This is written in the documentation of the program? You do read documentation, do you? 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. These settings are for single user / small user numbers boxes. If you're using an out of the vendor box distribution configuration for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your consultant is an idiot. Regards Henning I guess all customers are idiots then, since about 100+ people who were using our release downloaded it, and had these problems with sendmail. This disconnect of yours is about what I would expect from someone in a University. Some of us don't have the luxury of being able to pontificate in a Univ environment -- we have to make a living from Linux -- and provide payroll for the people on this list who actually do the core work on Linux. If there were not a commercialization effort around Linux, it would still be unknown, like TMOK or a lot of other kernels sitting in universities somewhere not being deployed. It's the commercialization effort that made Linux a household word. NT and NetWare servers don't stop forwarding emails when the load average gets too high -- they just work out of the box, and hopefully, no so will Linux (our distribution does now since this problem in fixed). Now we know that sendmail has problems on Linux based on the this load average interpretation, which we would not have known if someone had not raised the issue. This is not a problem with sendmail on Linux. The same thing will happen on ANY uni-processor system (multi-processor too, but not as severe). I run sendmail on an SGI Indy (yes, that no-longer-manufactured thing) and it is necessary to set the load average on it to 75 or so. As high as 150 is not unreasonable either. This system handles 10's of thousands of mail messages per day. This is only a matter of tuning sendmail to do what you want, when you want. It is also reasonably well documented in the sendmail distribution. You do have to monitor the system to determine what "high" really is. In the case of the NT servers, I have seen them choke (and crash) since they DON'T seem to throttle very well. BTW, After I read the sendmail documentation, and observed the system for a while, I decided to count the sendmail "loadaverage" as really being the average number of simultaneous connections (sendmail processes/threads). This leads to the choice of "how many do I want active, and how many do I want to suspended, and when do I want to refuse connection". THEN I add the number of other active processes to the proposed limits. -- - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Claus Assmann <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Why does Linux report a LA of 10 if there are only two processes > > running? > > > > Load Average = runnable processes (R) + processes in disk wait (D). Keep in mind that on some operating systems, sometimes processes become STUCK in "short disk wait". That may mean that if you just discard those processes (they won't do any useful work until you reboot the system), you will see the load average one point higher than what should be expected. This is almost always a bug somewhere. So, if you're not actually loading the machine with 12 processes doing disk IO, and still seeing a load of 12, chances are that there are processes stuck in the (D) state. That's a bug. Report the bug. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote:
> Ralf Baechle wrote:
> >
> > Jeff,
> >
> > On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
> >
> > > 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
> > > > 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(_lock);
> > for_each_task(p) {
> > if ((p->state == TASK_RUNNING ||
> > (p->state & TASK_UNINTERRUPTIBLE)))
> > nr += FIXED_1;
> > }
> > read_unlock(_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.
So everyone should up their defaults for most commercial Linux versions.
Jeff
>
> -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
I have this exact argument at work every so often. People coming in from an NT environment have difficulty understanding what it is/means and that it's not neccessarily bad when load gets above 1, etc, etc, etc. Ralf Baechle wrote: > > On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: > > > 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 -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Ralf Baechle wrote:
>
> Jeff,
>
> On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
>
> > 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
> > > 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(_lock);
> for_each_task(p) {
> if ((p->state == TASK_RUNNING ||
> (p->state & TASK_UNINTERRUPTIBLE)))
> nr += FIXED_1;
> }
> read_unlock(_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
--
<[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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Jeff,
On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
> 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
> > 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(_lock);
for_each_task(p) {
if ((p->state == TASK_RUNNING ||
(p->state & TASK_UNINTERRUPTIBLE)))
nr += FIXED_1;
}
read_unlock(_lock);
return nr;
}
Ralf
-
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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Ralf Baechle wrote: > > On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: > > > 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. > Actually, what most people expect it to represent is schedulability of new tasks. The problem is more one of: a) Expecting a fixed relationship between the specific number and the behaviour of the machine; b) The long time constants. On an 8-way machine a load average of 16 is not particularly high, even if you only count runnable processes, for example. -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: > 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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Followup to: <[EMAIL PROTECTED]> By author:Claus Assmann <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Why does Linux report a LA of 10 if there are only two processes > running? > Load Average = runnable processes (R) + processes in disk wait (D). -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[ ... named redacted by request ... ] wrote: > > > 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 > >> 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. > > If that is _our_ man page, it is broken. (well, old) Otherwise, > this is just a case of not mindlessly obeying the BSD "standard". > > Linux 2.4.xx includes some blocked processes in the load average > calculation. This is because the BSD load average calculation > could give a load of 0.0 when the system is severely overloaded > by IO. I think only uninterruptable processes got added in. > > Maybe this isn't the best solution... there could have been > a second load average for IO maybe. > > Feel free to forward this to the sendmail people, to the BSD people > in case they'd like to "standardize" the new calculation, or to the > linux-kernel mailing list for discussion -- w/o my name please. Forwarded at the request of a tier 1 Linux person after redacting their name. Jeff - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Claus Assmann wrote: > > On Fri, Nov 10, 2000, Jeff V. Merkey wrote: > > > 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 You said there were TCPIP timeout bugs. I can go retrieve the email. If there's this type of problem, the linux folks need to know so it can get fixed. Jeff > > 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:Neil W Rickert <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > > > > >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. 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 > 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. So I guess we know where we stand with the sendmail folks. If the US post office delivered mail at Christmas time using a size based priority the way sendmail does, folks would all get their Christmas presents about mid-February unless O NumberOfPostalWorkers=20 was set high enough. Jeff > > -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/ - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000, Jeff V. Merkey wrote: > 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000, David Lang wrote: > how many CPUs in these high loadave boxes? unless you have a very > impressive machine (8+SMP) the defaults should be plenty high. > > also I thought the QueueLA default was 8 and the RefuseLA was 12 or have > they been bumped up since I last examined them (8.8/8.9 timeframes) Those are the defaults. Jeff quoted the values from the .cf file I edited on his machine to get the e-mails through. > > We got to the bottom of the sendmail problem. The line: > > > > -O QueueLA=20 > > > > and > > > > -O RefuseLA=18 Why does Linux report a LA of 10 if there are only two processes running? - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Alexander Viro wrote: > > On Fri, 10 Nov 2000, Jeff V. Merkey wrote: > > > > > 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 in Linux (which we have now disproved). Even despite the limits being low, a "sendmail -v -q" command should always force delivery, and this wasn't even working right. This box gets hammered day and night with FTP activity. Had to upgrade since I learned when you post a free Linux distriution, everyone beats a path to your door. Jeff - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Followup to: <[EMAIL PROTECTED]> By author:Neil W Rickert <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > > >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. -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, 10 Nov 2000, Jeff V. Merkey wrote: > > 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, 10 Nov 2000, Neil W Rickert wrote: > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > > >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. It _depends_ on what the kernel is doing. In my Co. We've our MTA ( PIII 800 ) with LA > 40 often ... but it's processing a sustained load of 12 msg/hour. - Davide - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
David Lang wrote: > > how many CPUs in these high loadave boxes? unless you have a very > impressive machine (8+SMP) the defaults should be plenty high. > > also I thought the QueueLA default was 8 and the RefuseLA was 12 or have > they been bumped up since I last examined them (8.8/8.9 timeframes) I think this may be related to VM activity. I looked at /proc/meminfo and the sendmail sickness seems directly related to heavy VM activity in the box. This may be one for Rik/Linus. I'm just trying to get Ute-NWFS out the door and want stuff to work. :-) Jeff > > David Lang > > On Fri, 10 Nov 2000, Jeff V. Merkey wrote: > > > Date: Fri, 10 Nov 2000 14:52:01 -0700 > > From: Jeff V. Merkey <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Subject: Re: sendmail fails to deliver mail with attachments in > > /var/spool/mqueue > > > > > > > > Hey guys, > > > > We got to the bottom of the sendmail problem. The line: > > > > -O QueueLA=20 > > > > and > > > > -O RefuseLA=18 > > > > Need to be cranked up in sendmail.cf to something high since the > > background VM on a very busy Linux box seems to exceed this which causes > > large emails to get stuck in the /var/spool/mqueue directory for long > > periods of time. Since vger is getting hammered with FTP all the time, > > and is rarely idle. This also explains what Richard was seeing with VM > > thrashing in a box with low memory. > > > > 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. > > > > Jeff > > > > "Jeff V. Merkey" wrote: > > > > > > Claus, > > > > > > This is a bug. emails should not get stuck in the mail queue because > > > your load averaging routine doesn't work right. If this is so, then why > > > do some emails (small ones) get through and big ones do not, > > > irreguardless of delivery order. If it were a loading problem one would > > > think emails would still get processed in the order they arrived, not > > > some arbitrary "order from hell" which is what was happening. This is > > > severely broken IMHO and you need to fix it. > > > > > > Jeff > > > > > > Claus Assmann wrote: > > > > > > > > All of these entries have an 'X': > > > > > > > > > Mail Queue (11 requests) > > > > > --Q-ID-- --Size-- -Priority- ---Q-Time--- >---Sender/Recipient--- > > > > > FAA15716X 31418 200564 Nov 9 05:01 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > FAA20318X 32693 201751 Nov 10 05:29 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > SAA01998X 34484 203865 Nov 6 18:20 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > QAA01341X 65091 204150 Nov 6 16:50 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > SAA13390X 41368 210478 Nov 8 18:03 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > LAA03425X 158115 218595 Nov 6 11:27 <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > QAA01343X 65091 234150 Nov 6 16:50 ><[EMAIL PROTECTED]> > > > > > 7BIT > > > > > <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > KAA21225X 205041 235799 Nov 10 10:26 <[EMAIL PROTECTED]> > > > > > 8BITMIME > > > > > <[EMAIL PROTECTED]> > > > > > FAA20229X1457 272283+Nov 10 05:01 <[EMAIL PROTECTED]> > > > > > (Warning: could not send message for past 1 hour) > > > > > <[EMAIL PROTECTED]> > > > > > QAA06681X 242511 272929 Nov 7 16:18 <[EMAIL PROTECTED]> > > > > > 8BITMIME > > > > > <[EMAIL PROTECTED]> > > > > > PAA12261X 576306 606701 Nov 8 15:06 <[EMAIL PROTECTED]> > > > > > <[EMAIL PROTECTED]> > > > > > > > > That is, the load on your machine is too high. > > > > 3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50 > > > > > > > > It seems as if this is
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
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. Jeff Neil W Rickert wrote: > > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: > > >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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
how many CPUs in these high loadave boxes? unless you have a very impressive machine (8+SMP) the defaults should be plenty high. also I thought the QueueLA default was 8 and the RefuseLA was 12 or have they been bumped up since I last examined them (8.8/8.9 timeframes) David Lang On Fri, 10 Nov 2000, Jeff V. Merkey wrote: > Date: Fri, 10 Nov 2000 14:52:01 -0700 > From: Jeff V. Merkey <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: sendmail fails to deliver mail with attachments in > /var/spool/mqueue > > > > Hey guys, > > We got to the bottom of the sendmail problem. The line: > > -O QueueLA=20 > > and > > -O RefuseLA=18 > > Need to be cranked up in sendmail.cf to something high since the > background VM on a very busy Linux box seems to exceed this which causes > large emails to get stuck in the /var/spool/mqueue directory for long > periods of time. Since vger is getting hammered with FTP all the time, > and is rarely idle. This also explains what Richard was seeing with VM > thrashing in a box with low memory. > > 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. > > Jeff > > "Jeff V. Merkey" wrote: > > > > Claus, > > > > This is a bug. emails should not get stuck in the mail queue because > > your load averaging routine doesn't work right. If this is so, then why > > do some emails (small ones) get through and big ones do not, > > irreguardless of delivery order. If it were a loading problem one would > > think emails would still get processed in the order they arrived, not > > some arbitrary "order from hell" which is what was happening. This is > > severely broken IMHO and you need to fix it. > > > > Jeff > > > > Claus Assmann wrote: > > > > > > All of these entries have an 'X': > > > > > > > Mail Queue (11 requests) > > > > --Q-ID-- --Size-- -Priority- ---Q-Time--- >---Sender/Recipient--- > > > > FAA15716X 31418 200564 Nov 9 05:01 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > FAA20318X 32693 201751 Nov 10 05:29 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > SAA01998X 34484 203865 Nov 6 18:20 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > QAA01341X 65091 204150 Nov 6 16:50 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > SAA13390X 41368 210478 Nov 8 18:03 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > LAA03425X 158115 218595 Nov 6 11:27 <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > QAA01343X 65091 234150 Nov 6 16:50 <[EMAIL PROTECTED]> > > > > 7BIT > > > > <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > KAA21225X 205041 235799 Nov 10 10:26 <[EMAIL PROTECTED]> > > > > 8BITMIME > > > > <[EMAIL PROTECTED]> > > > > FAA20229X1457 272283+Nov 10 05:01 <[EMAIL PROTECTED]> > > > > (Warning: could not send message for past 1 hour) > > > > <[EMAIL PROTECTED]> > > > > QAA06681X 242511 272929 Nov 7 16:18 <[EMAIL PROTECTED]> > > > > 8BITMIME > > > > <[EMAIL PROTECTED]> > > > > PAA12261X 576306 606701 Nov 8 15:06 <[EMAIL PROTECTED]> > > > > <[EMAIL PROTECTED]> > > > > > > That is, the load on your machine is too high. > > > 3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50 > > > > > > It seems as if this is broken, top shows 2 running processes > > > and 67 sleeping. > > > > > > If you run the queue with -O QueueLA=20 the entries are processed. > > > So you have to change your configuration to deal with the "high" > > > load, which I did right now by editing your .cf file. > - > 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/ > - To unsubscribe from this list: send the
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote: >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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Hey guys, We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. 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. Jeff "Jeff V. Merkey" wrote: > > Claus, > > This is a bug. emails should not get stuck in the mail queue because > your load averaging routine doesn't work right. If this is so, then why > do some emails (small ones) get through and big ones do not, > irreguardless of delivery order. If it were a loading problem one would > think emails would still get processed in the order they arrived, not > some arbitrary "order from hell" which is what was happening. This is > severely broken IMHO and you need to fix it. > > Jeff > > Claus Assmann wrote: > > > > All of these entries have an 'X': > > > > > Mail Queue (11 requests) > > > --Q-ID-- --Size-- -Priority- ---Q-Time--- ---Sender/Recipient--- > > > FAA15716X 31418 200564 Nov 9 05:01 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > FAA20318X 32693 201751 Nov 10 05:29 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > SAA01998X 34484 203865 Nov 6 18:20 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > QAA01341X 65091 204150 Nov 6 16:50 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > SAA13390X 41368 210478 Nov 8 18:03 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > LAA03425X 158115 218595 Nov 6 11:27 <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > QAA01343X 65091 234150 Nov 6 16:50 <[EMAIL PROTECTED]> > > > 7BIT > > > <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > KAA21225X 205041 235799 Nov 10 10:26 <[EMAIL PROTECTED]> > > > 8BITMIME > > > <[EMAIL PROTECTED]> > > > FAA20229X1457 272283+Nov 10 05:01 <[EMAIL PROTECTED]> > > > (Warning: could not send message for past 1 hour) > > > <[EMAIL PROTECTED]> > > > QAA06681X 242511 272929 Nov 7 16:18 <[EMAIL PROTECTED]> > > > 8BITMIME > > > <[EMAIL PROTECTED]> > > > PAA12261X 576306 606701 Nov 8 15:06 <[EMAIL PROTECTED]> > > > <[EMAIL PROTECTED]> > > > > That is, the load on your machine is too high. > > 3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50 > > > > It seems as if this is broken, top shows 2 running processes > > and 67 sleeping. > > > > If you run the queue with -O QueueLA=20 the entries are processed. > > So you have to change your configuration to deal with the "high" > > load, which I did right now by editing your .cf file. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"Jeff V. Merkey" [EMAIL PROTECTED] wrote: 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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
how many CPUs in these high loadave boxes? unless you have a very impressive machine (8+SMP) the defaults should be plenty high. also I thought the QueueLA default was 8 and the RefuseLA was 12 or have they been bumped up since I last examined them (8.8/8.9 timeframes) David Lang On Fri, 10 Nov 2000, Jeff V. Merkey wrote: Date: Fri, 10 Nov 2000 14:52:01 -0700 From: Jeff V. Merkey [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue Hey guys, We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. 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. Jeff "Jeff V. Merkey" wrote: Claus, This is a bug. emails should not get stuck in the mail queue because your load averaging routine doesn't work right. If this is so, then why do some emails (small ones) get through and big ones do not, irreguardless of delivery order. If it were a loading problem one would think emails would still get processed in the order they arrived, not some arbitrary "order from hell" which is what was happening. This is severely broken IMHO and you need to fix it. Jeff Claus Assmann wrote: All of these entries have an 'X': Mail Queue (11 requests) --Q-ID-- --Size-- -Priority- ---Q-Time--- ---Sender/Recipient--- FAA15716X 31418 200564 Nov 9 05:01 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] FAA20318X 32693 201751 Nov 10 05:29 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] SAA01998X 34484 203865 Nov 6 18:20 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] QAA01341X 65091 204150 Nov 6 16:50 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] SAA13390X 41368 210478 Nov 8 18:03 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] LAA03425X 158115 218595 Nov 6 11:27 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] QAA01343X 65091 234150 Nov 6 16:50 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] KAA21225X 205041 235799 Nov 10 10:26 [EMAIL PROTECTED] 8BITMIME [EMAIL PROTECTED] FAA20229X1457 272283+Nov 10 05:01 [EMAIL PROTECTED] (Warning: could not send message for past 1 hour) [EMAIL PROTECTED] QAA06681X 242511 272929 Nov 7 16:18 [EMAIL PROTECTED] 8BITMIME [EMAIL PROTECTED] PAA12261X 576306 606701 Nov 8 15:06 [EMAIL PROTECTED] [EMAIL PROTECTED] That is, the load on your machine is too high. 3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50 It seems as if this is broken, top shows 2 running processes and 67 sleeping. If you run the queue with -O QueueLA=20 the entries are processed. So you have to change your configuration to deal with the "high" load, which I did right now by editing your .cf file. - 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/ - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
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. Jeff Neil W Rickert wrote: "Jeff V. Merkey" [EMAIL PROTECTED] wrote: 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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
David Lang wrote: how many CPUs in these high loadave boxes? unless you have a very impressive machine (8+SMP) the defaults should be plenty high. also I thought the QueueLA default was 8 and the RefuseLA was 12 or have they been bumped up since I last examined them (8.8/8.9 timeframes) I think this may be related to VM activity. I looked at /proc/meminfo and the sendmail sickness seems directly related to heavy VM activity in the box. This may be one for Rik/Linus. I'm just trying to get Ute-NWFS out the door and want stuff to work. :-) Jeff David Lang On Fri, 10 Nov 2000, Jeff V. Merkey wrote: Date: Fri, 10 Nov 2000 14:52:01 -0700 From: Jeff V. Merkey [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue Hey guys, We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Need to be cranked up in sendmail.cf to something high since the background VM on a very busy Linux box seems to exceed this which causes large emails to get stuck in the /var/spool/mqueue directory for long periods of time. Since vger is getting hammered with FTP all the time, and is rarely idle. This also explains what Richard was seeing with VM thrashing in a box with low memory. 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. Jeff "Jeff V. Merkey" wrote: Claus, This is a bug. emails should not get stuck in the mail queue because your load averaging routine doesn't work right. If this is so, then why do some emails (small ones) get through and big ones do not, irreguardless of delivery order. If it were a loading problem one would think emails would still get processed in the order they arrived, not some arbitrary "order from hell" which is what was happening. This is severely broken IMHO and you need to fix it. Jeff Claus Assmann wrote: All of these entries have an 'X': Mail Queue (11 requests) --Q-ID-- --Size-- -Priority- ---Q-Time--- ---Sender/Recipient--- FAA15716X 31418 200564 Nov 9 05:01 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] FAA20318X 32693 201751 Nov 10 05:29 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] SAA01998X 34484 203865 Nov 6 18:20 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] QAA01341X 65091 204150 Nov 6 16:50 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] SAA13390X 41368 210478 Nov 8 18:03 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] LAA03425X 158115 218595 Nov 6 11:27 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] QAA01343X 65091 234150 Nov 6 16:50 [EMAIL PROTECTED] 7BIT [EMAIL PROTECTED] [EMAIL PROTECTED] KAA21225X 205041 235799 Nov 10 10:26 [EMAIL PROTECTED] 8BITMIME [EMAIL PROTECTED] FAA20229X1457 272283+Nov 10 05:01 [EMAIL PROTECTED] (Warning: could not send message for past 1 hour) [EMAIL PROTECTED] QAA06681X 242511 272929 Nov 7 16:18 [EMAIL PROTECTED] 8BITMIME [EMAIL PROTECTED] PAA12261X 576306 606701 Nov 8 15:06 [EMAIL PROTECTED] [EMAIL PROTECTED] That is, the load on your machine is too high. 3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50 It seems as if this is broken, top shows 2 running processes and 67 sleeping. If you run the queue with -O QueueLA=20 the entries are processed. So you have to change your configuration to deal with the "high" load, which I did right now by editing your .cf file. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, 10 Nov 2000, Neil W Rickert wrote: "Jeff V. Merkey" [EMAIL PROTECTED] wrote: 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. It _depends_ on what the kernel is doing. In my Co. We've our MTA ( PIII 800 ) with LA 40 often ... but it's processing a sustained load of 12 msg/hour. - Davide - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, 10 Nov 2000, Jeff V. Merkey wrote: 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Followup to: [EMAIL PROTECTED] By author:Neil W Rickert [EMAIL PROTECTED] In newsgroup: linux.dev.kernel "Jeff V. Merkey" [EMAIL PROTECTED] wrote: 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. -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Alexander Viro wrote: On Fri, 10 Nov 2000, Jeff V. Merkey wrote: 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 in Linux (which we have now disproved). Even despite the limits being low, a "sendmail -v -q" command should always force delivery, and this wasn't even working right. This box gets hammered day and night with FTP activity. Had to upgrade since I learned when you post a free Linux distriution, everyone beats a path to your door. Jeff - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000, David Lang wrote: how many CPUs in these high loadave boxes? unless you have a very impressive machine (8+SMP) the defaults should be plenty high. also I thought the QueueLA default was 8 and the RefuseLA was 12 or have they been bumped up since I last examined them (8.8/8.9 timeframes) Those are the defaults. Jeff quoted the values from the .cf file I edited on his machine to get the e-mails through. We got to the bottom of the sendmail problem. The line: -O QueueLA=20 and -O RefuseLA=18 Why does Linux report a LA of 10 if there are only two processes running? - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000, Jeff V. Merkey wrote: 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
"H. Peter Anvin" wrote: Followup to: [EMAIL PROTECTED] By author:Neil W Rickert [EMAIL PROTECTED] In newsgroup: linux.dev.kernel "Jeff V. Merkey" [EMAIL PROTECTED] wrote: 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. 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 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. So I guess we know where we stand with the sendmail folks. If the US post office delivered mail at Christmas time using a size based priority the way sendmail does, folks would all get their Christmas presents about mid-February unless O NumberOfPostalWorkers=20 was set high enough. Jeff -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/ - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Claus Assmann wrote: On Fri, Nov 10, 2000, Jeff V. Merkey wrote: 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 You said there were TCPIP timeout bugs. I can go retrieve the email. If there's this type of problem, the linux folks need to know so it can get fixed. Jeff 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. - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
[ ... named redacted by request ... ] wrote: 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 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. If that is _our_ man page, it is broken. (well, old) Otherwise, this is just a case of not mindlessly obeying the BSD "standard". Linux 2.4.xx includes some blocked processes in the load average calculation. This is because the BSD load average calculation could give a load of 0.0 when the system is severely overloaded by IO. I think only uninterruptable processes got added in. Maybe this isn't the best solution... there could have been a second load average for IO maybe. Feel free to forward this to the sendmail people, to the BSD people in case they'd like to "standardize" the new calculation, or to the linux-kernel mailing list for discussion -- w/o my name please. Forwarded at the request of a tier 1 Linux person after redacting their name. Jeff - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Followup to: [EMAIL PROTECTED] By author:Claus Assmann [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Why does Linux report a LA of 10 if there are only two processes running? Load Average = runnable processes (R) + processes in disk wait (D). -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: 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 - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Ralf Baechle wrote: On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: 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. Actually, what most people expect it to represent is schedulability of new tasks. The problem is more one of: a) Expecting a fixed relationship between the specific number and the behaviour of the machine; b) The long time constants. On an 8-way machine a load average of 16 is not particularly high, even if you only count runnable processes, for example. -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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Jeff,
On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
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
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;
}
Ralf
-
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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
Ralf Baechle wrote:
Jeff,
On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
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
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;
}
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
--
[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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
I have this exact argument at work every so often. People coming in from an NT environment have difficulty understanding what it is/means and that it's not neccessarily bad when load gets above 1, etc, etc, etc. Ralf Baechle wrote: On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote: 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 -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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/
Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote:
Ralf Baechle wrote:
Jeff,
On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
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
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;
}
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.
So everyone should up their defaults for most commercial Linux versions.
Jeff
-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/
