The sendmail folks are claiming that the TCPIP stack in Linux is broken,
which is what they claim is causing problems on sendmail on Linux
platforms. Before anyone says, "don't use that piece of shit sendmail,
use qmail instead", perhaps we should look at this problem and refute
these statements -- I think that sendmail is causing this problem. The
version is sendmail 8.9.3
I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
Suse 6.X versions, and any of these distributions with the following
kernels.
2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that
sendmail fails to forward mails with any attachments larger than 400K,
and they just sit in the /var/spool/mqueue directory for up to a week,
and eventually get delivered.
ANyone have any ideas if what the sendmail people are saying is on the
level, or is this just another sendmail bug.
Jeff
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> which is what they claim is causing problems on sendmail on Linux
> platforms. Before anyone says, "don't use that piece of shit sendmail,
> use qmail instead", perhaps we should look at this problem and refute
> these statements -- I think that sendmail is causing this problem. The
> version is sendmail 8.9.3
What about sendmail 8.11.1? Is the problem there too?
>
> I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
> Suse 6.X versions, and any of these distributions with the following
> kernels.
>
> 2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that
> sendmail fails to forward mails with any attachments larger than 400K,
> and they just sit in the /var/spool/mqueue directory for up to a week,
> and eventually get delivered.
>
> ANyone have any ideas if what the sendmail people are saying is on the
> level, or is this just another sendmail bug.
>
> Jeff
wfms
"William F. Maton" wrote:
>
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> >
> > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > which is what they claim is causing problems on sendmail on Linux
> > platforms. Before anyone says, "don't use that piece of shit sendmail,
> > use qmail instead", perhaps we should look at this problem and refute
> > these statements -- I think that sendmail is causing this problem. The
> > version is sendmail 8.9.3
>
> What about sendmail 8.11.1? Is the problem there too?
Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses
encryption.
>
> >
> > I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
> > Suse 6.X versions, and any of these distributions with the following
> > kernels.
> >
> > 2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that
> > sendmail fails to forward mails with any attachments larger than 400K,
> > and they just sit in the /var/spool/mqueue directory for up to a week,
> > and eventually get delivered.
> >
> > ANyone have any ideas if what the sendmail people are saying is on the
> > level, or is this just another sendmail bug.
> >
> > Jeff
>
> wfms
Any `real` reason you're still at 8.9.3? Current is 8.11.1
If you send me a note of the type that fails, (to [email protected]),
it'll get received on both a 2.2.18-21/8.11.1 and 2.4.0-test10/8.11.2.Beta0
system.
--
Rick Nelson
'Mounten' wird f?r drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken'
von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
-- Christa Keil
Richard A Nelson wrote:
>
> Any `real` reason you're still at 8.9.3? Current is 8.11.1
>
> If you send me a note of the type that fails, (to [email protected]),
> it'll get received on both a 2.2.18-21/8.11.1 and 2.4.0-test10/8.11.2.Beta0
8.11.1 has problems talking to older sendmails and qmail. I've seen
even worse problems on 8.11.1, and backreved it immediately, and the
encryption stuff has a lot of build problems on Linux.
Jeff
> system.
>
> --
> Rick Nelson
> 'Mounten' wird f?r drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken'
> von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
> -- Christa Keil
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> "William F. Maton" wrote:
> >
> > What about sendmail 8.11.1? Is the problem there too?
>
> Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses
> encryption.
Eh?!? TLS is an optional, negotiated protocol started *after* the two
sendmails are communicating.
I've not seen any problems, save a documented case with *one* third
party SMTP server (don't recall who it was).
--
Rick Nelson
Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
with an Oops-Oops here and an Oops-Oops there
here an Oops, there an Oops, everywhere an Oops-Oops.
-- [email protected], linux.dev.kernel
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 8.11.1 has problems talking to older sendmails and qmail. I've seen
> even worse problems on 8.11.1, and backreved it immediately, and the
> encryption stuff has a lot of build problems on Linux.
Sounds like local build problems, possibly all the problems !
I can assist if you want to build 8.11.1 on Linux
--
Rick Nelson
Life'll kill ya -- Warren Zevon
Then you'll be dead -- Life'll kill ya
Send me an email from it with an attachment > 1MB, and I will forward
back to you when (and if) It gets delivered before next week.
:-)
Jeff
Richard A Nelson wrote:
>
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> > "William F. Maton" wrote:
> > >
> > > What about sendmail 8.11.1? Is the problem there too?
> >
> > Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
>
> Eh?!? TLS is an optional, negotiated protocol started *after* the two
> sendmails are communicating.
>
> I've not seen any problems, save a documented case with *one* third
> party SMTP server (don't recall who it was).
>
> --
> Rick Nelson
> Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
> with an Oops-Oops here and an Oops-Oops there
> here an Oops, there an Oops, everywhere an Oops-Oops.
> -- [email protected], linux.dev.kernel
On Fri, 10 Nov 2000, Richard A Nelson wrote:
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> > "William F. Maton" wrote:
> > >
> > > What about sendmail 8.11.1? Is the problem there too?
> >
> > Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
>
> Eh?!? TLS is an optional, negotiated protocol started *after* the two
> sendmails are communicating.
You anticipated what I was about to type :-)
> I've not seen any problems, save a documented case with *one* third
> party SMTP server (don't recall who it was).
No problems here either...
>
> --
> Rick Nelson
> Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
> with an Oops-Oops here and an Oops-Oops there
> here an Oops, there an Oops, everywhere an Oops-Oops.
> -- [email protected], linux.dev.kernel
>
wfms
Since I posted this on LKML, Claus over at sendmail.org seems more
motivated to track it down. (since it might appear on the front page of
Linux today). I would love your assistance Richard.
It could be a local problem since smrsh also seems to be f_cked up as
well, but I am seeing the same thing with an out of the box RH6.2.
Jeff
Richard A Nelson wrote:
>
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> > 8.11.1 has problems talking to older sendmails and qmail. I've seen
> > even worse problems on 8.11.1, and backreved it immediately, and the
> > encryption stuff has a lot of build problems on Linux.
>
> Sounds like local build problems, possibly all the problems !
>
> I can assist if you want to build 8.11.1 on Linux
> --
> Rick Nelson
> Life'll kill ya -- Warren Zevon
> Then you'll be dead -- Life'll kill ya
>
> -
> 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/
Claus is sloging into the box and we will be trying to track this down.
If it is a problem in the Linux TCPIP stack, we'll post a report later
this afternoon as to where it looks like the problem is.
Jeff
"Jeff V. Merkey" wrote:
>
> Since I posted this on LKML, Claus over at sendmail.org seems more
> motivated to track it down. (since it might appear on the front page of
> Linux today). I would love your assistance Richard.
> It could be a local problem since smrsh also seems to be f_cked up as
> well, but I am seeing the same thing with an out of the box RH6.2.
>
> Jeff
>
> Richard A Nelson wrote:
> >
> > On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> >
> > > 8.11.1 has problems talking to older sendmails and qmail. I've seen
> > > even worse problems on 8.11.1, and backreved it immediately, and the
> > > encryption stuff has a lot of build problems on Linux.
> >
> > Sounds like local build problems, possibly all the problems !
> >
> > I can assist if you want to build 8.11.1 on Linux
> > --
> > Rick Nelson
> > Life'll kill ya -- Warren Zevon
> > Then you'll be dead -- Life'll kill ya
> >
> > -
> > 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/
On Fri, 10 Nov 2000, William F. Maton wrote:
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> >
> > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > which is what they claim is causing problems on sendmail on Linux
> > platforms. Before anyone says, "don't use that piece of shit sendmail,
> > use qmail instead", perhaps we should look at this problem and refute
> > these statements -- I think that sendmail is causing this problem. The
> > version is sendmail 8.9.3
>
> What about sendmail 8.11.1? Is the problem there too?
>
I am running sendmail-8.11-0.Beta3 on Linux 2.4.0-test9. I didn't
have any problem with it (except that the documentation sucks,
making it extremely difficult to configure). Once configured, it runs
fine. It also ran fine on Linux-2.2.17.
If something is staying in the mail-queue `mailq`, this means that
the daemon isn't running. It may have crashed. This can be caused
by somebody keeping some mailer entry in /etc/inetd.conf. Sendmail
has to run as a daemon with no other interference on port 25.
Check the configuration.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Fri, Nov 10, 2000 at 11:45:39AM -0700, Jeff V. Merkey wrote:
> > > > > [..] Issuing the command "sendmail -v
> > > > > -q" does not flush the mail queue. [..]
So first thing to do is to check that in /etc/sendmail.cf this line is
commented out this way:
#O HostStatusDirectory=...
(if you build .cf via m4 add this line:
undefine(`confHOST_STATUS_DIRECTORY')dnl
and rebuild the .cf from the m4 source)
Then `rcsendmail reload; sendmail -q; mailq`.
Andrea
"Richard B. Johnson" wrote:
>
> On Fri, 10 Nov 2000, William F. Maton wrote:
>
> > On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> >
> > >
> > > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > > which is what they claim is causing problems on sendmail on Linux
> > > platforms. Before anyone says, "don't use that piece of shit sendmail,
> > > use qmail instead", perhaps we should look at this problem and refute
> > > these statements -- I think that sendmail is causing this problem. The
> > > version is sendmail 8.9.3
> >
> > What about sendmail 8.11.1? Is the problem there too?
> >
>
> I am running sendmail-8.11-0.Beta3 on Linux 2.4.0-test9. I didn't
> have any problem with it (except that the documentation sucks,
> making it extremely difficult to configure). Once configured, it runs
> fine. It also ran fine on Linux-2.2.17.
>
> If something is staying in the mail-queue `mailq`, this means that
> the daemon isn't running. It may have crashed. This can be caused
> by somebody keeping some mailer entry in /etc/inetd.conf. Sendmail
> has to run as a daemon with no other interference on port 25.
> Check the configuration.
I did Dick. The config is fine. The daemon is also fine and running.
What's really weird is that even if I do a "sendmail -v -q" command
(which should force the queue to flush) it still doesn't.
Jeff
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
Andrea,
All done. It's already setup this way.
Jeff
Andrea Arcangeli wrote:
>
> On Fri, Nov 10, 2000 at 11:45:39AM -0700, Jeff V. Merkey wrote:
> > > > > > [..] Issuing the command "sendmail -v
> > > > > > -q" does not flush the mail queue. [..]
>
> So first thing to do is to check that in /etc/sendmail.cf this line is
> commented out this way:
>
> #O HostStatusDirectory=...
>
> (if you build .cf via m4 add this line:
>
> undefine(`confHOST_STATUS_DIRECTORY')dnl
>
> and rebuild the .cf from the m4 source)
>
> Then `rcsendmail reload; sendmail -q; mailq`.
>
> Andrea
On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
>
> Andrea,
>
> All done. It's already setup this way.
Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
what's going wrong in the TCP connection to the smtp server:
tcpdump port smtp
Andrea
On Fri, 10 Nov 2000, Andrea Arcangeli wrote:
> On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
> >
> > Andrea,
> >
> > All done. It's already setup this way.
>
> Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
> what's going wrong in the TCP connection to the smtp server:
>
> tcpdump port smtp
>
> Andrea
I tried to send Jeff a 45 Megabyte file. It is still in the queue.
FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
[SNIPPED...]
140 0 82 1 9 0 840 100 do_select S ?
0:00 /usr/sbin/rpc.pcnfsd /var/spool/lpd
140 0 86 1 8 0 1744 364 do_select S ?
0:00 sendmail: accepting connections
40 0 5742 1 16 0 1812 136 wait_for_tc S ? 0:01
sendmail: ./eAAJm8V05731 vger.timpanogas.org.: client DATA 354
It isn't a TCP/IP stack problem. It may be a memory problem. Every time
sendmail spawns a child to send the file data, it crashes. That's
why the file never gets sent!
This is how /proc/meminfo looks right after it crashes. There has
been a lot of swapping going on.
total: used: free: shared: buffers: cached:
Mem: 328114176 38932480 289181696 0 2293760 27115520
Swap: 139821056 10014720 129806336
MemTotal: 320424 kB
MemFree: 282404 kB
MemShared: 0 kB
Buffers: 2240 kB
Cached: 26484 kB
Active: 5576 kB
Inact_dirty: 18348 kB
Inact_clean: 4800 kB
Inact_target: 332 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 320424 kB
LowFree: 282400 kB
SwapTotal: 136544 kB
SwapFree: 126764 kB
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes. That's
> why the file never gets sent!
Sure that could be the case. You should be able to verify the kernel kills the
task with `dmesg`.
However Jeff said the problem happens over 400K and a 500K attachment shouldn't
really run any machine out of memory, so maybe this wasn't his same problem?
Andrea
Andrea Arcangeli wrote:
>
> On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > sendmail spawns a child to send the file data, it crashes. That's
> > why the file never gets sent!
>
> Sure that could be the case. You should be able to verify the kernel kills the
> task with `dmesg`.
>
> However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> really run any machine out of memory, so maybe this wasn't his same problem?
I think it is. So it looks like sendmail is bombing when it attempts to
send large files.
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/
Andre,
SSH is running on this system, so send me your IP address to add to the
hosts.allow file and I'll send you an account so you can get into the
box and see just what's happening with ssh. Andre Hedrick has root
privileges on this machine, so if I'm ever not around, he can get into
it. I am running 2.2.18pre19 on i right now, and was going to upgrade
to 2.2.18-pre20 this evening, but let's look into this first since Alan
may have another patch to post ....
8)
Jeff
"Richard B. Johnson" wrote:
>
> On Fri, 10 Nov 2000, Andrea Arcangeli wrote:
>
> > On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
> > >
> > > Andrea,
> > >
> > > All done. It's already setup this way.
> >
> > Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
> > what's going wrong in the TCP connection to the smtp server:
> >
> > tcpdump port smtp
> >
> > Andrea
>
> I tried to send Jeff a 45 Megabyte file. It is still in the queue.
>
> FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
> [SNIPPED...]
>
> 140 0 82 1 9 0 840 100 do_select S ?
> 0:00 /usr/sbin/rpc.pcnfsd /var/spool/lpd
> 140 0 86 1 8 0 1744 364 do_select S ?
> 0:00 sendmail: accepting connections
> 40 0 5742 1 16 0 1812 136 wait_for_tc S ? 0:01
> sendmail: ./eAAJm8V05731 vger.timpanogas.org.: client DATA 354
>
> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes. That's
> why the file never gets sent!
>
> This is how /proc/meminfo looks right after it crashes. There has
> been a lot of swapping going on.
>
> total: used: free: shared: buffers: cached:
> Mem: 328114176 38932480 289181696 0 2293760 27115520
> Swap: 139821056 10014720 129806336
> MemTotal: 320424 kB
> MemFree: 282404 kB
> MemShared: 0 kB
> Buffers: 2240 kB
> Cached: 26484 kB
> Active: 5576 kB
> Inact_dirty: 18348 kB
> Inact_clean: 4800 kB
> Inact_target: 332 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 320424 kB
> LowFree: 282400 kB
> SwapTotal: 136544 kB
> SwapFree: 126764 kB
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
> -
> 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/
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
>
> Andrea Arcangeli wrote:
> >
> > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > sendmail spawns a child to send the file data, it crashes. That's
> > > why the file never gets sent!
> >
> > Sure that could be the case. You should be able to verify the kernel kills the
> > task with `dmesg`.
> >
> > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > really run any machine out of memory, so maybe this wasn't his same problem?
>
> I think it is. So it looks like sendmail is bombing when it attempts to
> send large files.
>
> Jeff
>
Yes. I was finally able to send Jeff a very large file. I had
to get rid of all the other memory consumers on this system.
Once it had enough memory, it got sent.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Fri, 10 Nov 2000, Andrea Arcangeli wrote:
> On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > sendmail spawns a child to send the file data, it crashes. That's
> > why the file never gets sent!
>
> Sure that could be the case. You should be able to verify the kernel kills the
> task with `dmesg`.
>
> However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> really run any machine out of memory, so maybe this wasn't his same problem?
>
> Andrea
>
It ran out of memory. The file got sent fine after I got rid of
all the memory-consumers. Looks like a sendmail bug where they
expect to load a whole file into memory all at once before sending
it. I always thought you could read from a file, then write to
a socket. Maybe I'm old fashioned.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
"Richard B. Johnson" wrote:
>
>
>
> It ran out of memory. The file got sent fine after I got rid of
> all the memory-consumers. Looks like a sendmail bug where they
> expect to load a whole file into memory all at once before sending
> it. I always thought you could read from a file, then write to
> a socket. Maybe I'm old fashioned.
>
> Cheers,
> Dick Johnson
>
Claus,
Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
OpenLinux all exhibit this behavior, which means they're all broken.
Reading an entire file into memory must be a BSD feature. I have
enabled an SSH account for you, so you can come in and debug. Richard
also can get in and will be helping.
Jeff
On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> "Richard B. Johnson" wrote:
> > It ran out of memory. The file got sent fine after I got rid of
> > all the memory-consumers. Looks like a sendmail bug where they
> > expect to load a whole file into memory all at once before sending
> > it. I always thought you could read from a file, then write to
On which evidence do you base this idea?
> > a socket. Maybe I'm old fashioned.
Yeah, just like us.
Please provide some proof to your claims.
> Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
> OpenLinux all exhibit this behavior, which means they're all broken.
Sorry, this is plain wrong. sendmail does NOT read the entire
file into memory.
> Reading an entire file into memory must be a BSD feature. I have
> enabled an SSH account for you, so you can come in and debug. Richard
> also can get in and will be helping.
What's the machine name and what's the account?
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> Andrea Arcangeli wrote:
> >
> > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > sendmail spawns a child to send the file data, it crashes. That's
> > > why the file never gets sent!
> >
> > Sure that could be the case. You should be able to verify the kernel kills the
> > task with `dmesg`.
> >
> > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > really run any machine out of memory, so maybe this wasn't his same problem?
>
> I think it is. So it looks like sendmail is bombing when it attempts to
> send large files.
Not to use the 'S-word', but we're receiving/sending biggish attachments
(7MB-9MB) under Solaris 2.6. Could sendmail be triggering a linux bug, or
could something specific to linux be triggering a sendmail bug?
> Jeff
wfms
On Fri, 10 Nov 2000, Claus Assmann wrote:
> On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
> > OpenLinux all exhibit this behavior, which means they're all broken.
>
> Sorry, this is plain wrong. sendmail does NOT read the entire
> file into memory.
Does sendmail use sendfile() ?
- Davide
"William F. Maton" wrote:
>
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> > Andrea Arcangeli wrote:
> > >
> > > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > > sendmail spawns a child to send the file data, it crashes. That's
> > > > why the file never gets sent!
> > >
> > > Sure that could be the case. You should be able to verify the kernel kills the
> > > task with `dmesg`.
> > >
> > > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > > really run any machine out of memory, so maybe this wasn't his same problem?
> >
> > I think it is. So it looks like sendmail is bombing when it attempts to
> > send large files.
>
> Not to use the 'S-word', but we're receiving/sending biggish attachments
> (7MB-9MB) under Solaris 2.6. Could sendmail be triggering a linux bug, or
> could something specific to linux be triggering a sendmail bug?
Richard has determined that it's a low memory problem on Linux with
sendmail. Perhaps it affects Solaris as well, try it in low memory with
a big file.
Jeff
>
> > Jeff
>
> wfms
On Fri, Nov 10, 2000, Davide Libenzi wrote:
[Please use a MTA that sends the e-mail only once to a given machine,
we got three copies of this]
> On Fri, 10 Nov 2000, Claus Assmann wrote:
> > On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > > Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
> > > OpenLinux all exhibit this behavior, which means they're all broken.
> >
> > Sorry, this is plain wrong. sendmail does NOT read the entire
> > file into memory.
>
> Does sendmail use sendfile() ?
No. Just do a grep on the source code.
I suspect that procmail is used which actually used to load
the entire mail into memory.
Followup to: <[email protected]>
By author: Davide Libenzi <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Fri, 10 Nov 2000, Claus Assmann wrote:
> > On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > > Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
> > > OpenLinux all exhibit this behavior, which means they're all broken.
> >
> > Sorry, this is plain wrong. sendmail does NOT read the entire
> > file into memory.
>
> Does sendmail use sendfile() ?
>
Or mmap()/write()?
-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
> > What about sendmail 8.11.1? Is the problem there too?
>
> Yes. Plus 8.11.1 has problems talking to older sendmails sine it uses
> encryption.
Depends on how you configure it. An enabled encryption doesn't always mean
it has problems taking to other sendmails. This sendmail here has no
problems forwarding a mail > 400 Kb (I used 1.2 MB).
This is 8.11.1 with the MySQL mapper patch.
> > > ANyone have any ideas if what the sendmail people are saying is on the
> > > level, or is this just another sendmail bug.
I can't reproduce on 8.11.1
Maybe I can if someones tells me the exact procedure to reproduce it.
> > >
> > > Jeff
> >
> > wfms
Igmar
> > It ran out of memory. The file got sent fine after I got rid of
> > all the memory-consumers. Looks like a sendmail bug where they
> > expect to load a whole file into memory all at once before sending
> > it. I always thought you could read from a file, then write to
> > a socket. Maybe I'm old fashioned.
Sending a 50 MB file is OK here. So it's not a TCP/IP bug.
> Claus,
>
> Looks like your bug. As an FYI, sendmail.rpms in Suse, RedHat, and
> OpenLinux all exhibit this behavior, which means they're all broken.
> Reading an entire file into memory must be a BSD feature. I have
> enabled an SSH account for you, so you can come in and debug. Richard
> also can get in and will be helping.
>
> Jeff
Igmar
On Sat, Nov 11, 2000, Igmar Palsenberg wrote:
>
> > > It ran out of memory. The file got sent fine after I got rid of
> > > all the memory-consumers. Looks like a sendmail bug where they
> > > expect to load a whole file into memory all at once before sending
> > > it. I always thought you could read from a file, then write to
As I wrote before: this is just wrong. sendmail doesn't
load the file into memory.
> > > a socket. Maybe I'm old fashioned.
>
> Sending a 50 MB file is OK here. So it's not a TCP/IP bug.
Ok, hopefully this reaches everyone who has been "involved"
by Jeff into this "problem".
It turned out that this was just a misconfiguration on his box
(the load average exceeded the limit of his sendmail).
Can we please close this case now? Thanks.
Claus Assmann wrote:
>
> On Sat, Nov 11, 2000, Igmar Palsenberg wrote:
> >
> > > > It ran out of memory. The file got sent fine after I got rid of
> > > > all the memory-consumers. Looks like a sendmail bug where they
> > > > expect to load a whole file into memory all at once before sending
> > > > it. I always thought you could read from a file, then write to
>
> As I wrote before: this is just wrong. sendmail doesn't
> load the file into memory.
>
> > > > a socket. Maybe I'm old fashioned.
> >
> > Sending a 50 MB file is OK here. So it's not a TCP/IP bug.
>
> Ok, hopefully this reaches everyone who has been "involved"
> by Jeff into this "problem".
>
> It turned out that this was just a misconfiguration on his box
> (the load average exceeded the limit of his sendmail).
>
> Can we please close this case now? Thanks.
There was also an issue relative to how sendmail is interpreting load
average on a linux box. [email protected] pointed out that perhaps you
are not factoring sleeping processes, which Linux does -- a deviation
from BSD's interpretation of load average. With a handle like
"Assmann", deviation is proably something you already understand quite
well ...
8)
Jeff
Jeff V. Merkey writes:
> There was also an issue relative to how sendmail is interpreting load
> average on a linux box. [email protected] pointed out that perhaps you
> are not factoring sleeping processes, which Linux does -- a deviation
> from BSD's interpretation of load average.
At worst it's an issue with how Linux presents load average, not with
how sendmail interprets it -- sendmail believes what the kernel tells
it. And from the sound of it, it's not even Linux's fault -- your box
has a high load average because it's got a lot of runnable processes.
> With a handle like
> "Assmann", deviation is proably something you already understand quite
> well ...
Don't be a moron. Claus is German, Assman really is his last name and
not some "handle", and it's pronounced "Oss-man".
I'm sure we could make plenty of stupid puns with "Merkey" too.
> > With a handle like
> > "Assmann", deviation is proably something you already understand quite
> > well ...
>
> Don't be a moron. Claus is German, Assman really is his last name and
> not some "handle", and it's pronounced "Oss-man".
Claus is a well liked, knowledgable and well experienced person in numerous
domains. Please don't stoop to such silly games with people's proper name.
-d
--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
On Fri, Nov 10, 2000 at 05:15:53PM -0800, Steve VanDevender wrote:
> Jeff V. Merkey writes:
> > There was also an issue relative to how sendmail is interpreting load
> > average on a linux box. [email protected] pointed out that perhaps you
> > are not factoring sleeping processes, which Linux does -- a deviation
> > from BSD's interpretation of load average.
>
> At worst it's an issue with how Linux presents load average, not with
> how sendmail interprets it -- sendmail believes what the kernel tells
> it. And from the sound of it, it's not even Linux's fault -- your box
> has a high load average because it's got a lot of runnable processes.
>
> > With a handle like
> > "Assmann", deviation is proably something you already understand quite
> > well ...
>
> Don't be a moron. Claus is German, Assman really is his last name and
> not some "handle", and it's pronounced "Oss-man".
>
> I'm sure we could make plenty of stupid puns with "Merkey" too.
I had no idea, I was making a joke. It looked like a handle, I apologize
for being culturally ignorant of being able to distinguishing it.
8)
jeff
On Fri, Nov 10, 2000 at 06:02:28PM -0800, David Ford wrote:
> > > With a handle like
> > > "Assmann", deviation is proably something you already understand quite
> > > well ...
> >
> > Don't be a moron. Claus is German, Assman really is his last name and
> > not some "handle", and it's pronounced "Oss-man".
>
> Claus is a well liked, knowledgable and well experienced person in numerous
> domains. Please don't stoop to such silly games with people's proper name.
Sounded like a handle of some kind, like Santa Claus or something. I had no
idea. I speak some native american, and I'm certain if I used "Oi-ach
Ch'ei e'ho" as a a email handle, many folks would be confused, when what I
was trying to say is my proper (non-english) name.
Jeff
>
> -d
>
> --
> "The difference between 'involvement' and 'commitment' is like an
> eggs-and-ham breakfast: the chicken was 'involved' - the pig was
> 'committed'."
>
>
Content-Description: Card for David Ford
[email protected] (Jeff V. Merkey) writes:
>I did Dick. The config is fine. The daemon is also fine and running.
>What's really weird is that even if I do a "sendmail -v -q" command
>(which should force the queue to flush) it still doesn't.
O Timeout.ident=0s
O Timeout.initial=30s (these are the ninieties / 21st century)
Get someone that really has an idea about sendmail.
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
[email protected] (Jeff V. Merkey) writes:
>The sendmail folks are claiming that the TCPIP stack in Linux is broken,
>which is what they claim is causing problems on sendmail on Linux
>platforms. Before anyone says, "don't use that piece of shit sendmail,
>use qmail instead", perhaps we should look at this problem and refute
>these statements -- I think that sendmail is causing this problem. The
>version is sendmail 8.9.3
>I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
>Suse 6.X versions, and any of these distributions with the following
>kernels.
>2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all). What happens is that
>sendmail fails to forward mails with any attachments larger than 400K,
>and they just sit in the /var/spool/mqueue directory for up to a week,
>and eventually get delivered.
Jeff,
I run about three dozen sendmail server boxes (8.9.3 to 8.11.1) on all
these platforms and each one of these boxes transfer 1,000,000+ Mails
per week (yes, this is one million).
There is _no_ _such_ _bug_. Maybe you get bitten by some bogus traffic
shapers (you did read the report from Wietse, didn't you). If there
would be such a bug, I believe, that any of the 10,000+ Customers
would start complaining.
But there is no problem with mails in any size and sendmail on Linux.
And I'm pretty much annoyed that you try to use this list not as a
kernel but a general linux-support list, because you drag every single
problem that may be far out related to a kernel, because it runs on a
kernel into this list.
Pay some $$$ for professional tech support. And use this list as a
kernel development list. Not some "I have no idea but I am a Netware
buff that has some money, so you have to listen to me or I will strike
you with my anger" rant list.
End of discussion
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
[email protected] (Claus Assmann) writes:
>> Sending a 50 MB file is OK here. So it's not a TCP/IP bug.
>Ok, hopefully this reaches everyone who has been "involved"
>by Jeff into this "problem".
So it is _once_ _again_ a Jeff "I have no clue but I know Linux-Kernel
list is cheaper than tech support or a real admin, but my real problem
sits on the chair in front of the display" Merkey problem.
This makes me puke. Again and again.
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
On Sat, Nov 11, 2000 at 01:24:18PM +0000, Henning P. Schmiedehausen wrote:
> [email protected] (Jeff V. Merkey) writes:
>
> >I did Dick. The config is fine. The daemon is also fine and running.
> >What's really weird is that even if I do a "sendmail -v -q" command
> >(which should force the queue to flush) it still doesn't.
>
> O Timeout.ident=0s
> O Timeout.initial=30s (these are the ninieties / 21st century)
>
> Get someone that really has an idea about sendmail.
>
> Regards
> Henning
Ha ha. It's fixed.
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/