Koozali.org: home of the SME Server

Sme 7.6 hang (crash) on large mail.

Offline tomeratch

  • *
  • 24
  • +0/-0
Sme 7.6 hang (crash) on large mail.
« on: September 14, 2012, 10:10:25 AM »
My sme 7.6 recently hang when it receives messages above 10mb
the default message size limit is set to 15mb. (still can ping the machine and get response when this happen but nothing else works ) after the hang, have to hard reset the server using the power button.
never had problems like this before any suggestions where to look to find the problem?
Thank you in advance 

Offline mmccarn

  • *
  • 2,626
  • +10/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #1 on: September 14, 2012, 12:37:32 PM »
Are all of the email subsystems set to support 15M attachments (http://wiki.contribs.org/SME_Server:Documentation:FAQ#Set_max_email_size)?

Is your 10M file compressed?  (If so, clamav un-compresses it in order to do a virus scan, which may cause problems).

Do you have an MTU size issue (http://bugs.contribs.org/show_bug.cgi?id=6888)?

Offline tomeratch

  • *
  • 24
  • +0/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #2 on: September 14, 2012, 09:18:48 PM »
thank you for your reply
I have a pineapp (anti-spam hardware) and when I check the machine it is always in a stage of trying to deliver a mail or more of above 10 mb to the SME server .
at first I tried to enable more concurrent sessions (its set to 250 now) from same ip (i tought that might couse the problem) but still the hang happens.
and it only happens whe a bulk of messages is sent with attachments.
when I reset the sme server all mail from pineapp go trough.(including the ones with 10 mb and above).
anyway I did vheck the things you asked . Clamv is off (for I use pineapp as a virus and spam scan).
the mtu link posted is not working for me ...(cant see the bug report).
and yes all email subsystems is set to 15000000.
any ideas?? its only happening lately ...

Offline mmccarn

  • *
  • 2,626
  • +10/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #3 on: September 14, 2012, 10:38:00 PM »
http://bugs.contribs.org/show_bug.cgi?id=6888

Basically, are there any network segments between your SME and your PineApp that may have an MTU below 1500.

Do you have to restart the SME?  Have you tried restarting individual services (qmail, qpsmtpd, clamd, qmail)?

Do the large attachments mostly go to the same user(s)?  Do any of those users have quota problems?


Offline tomeratch

  • *
  • 24
  • +0/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #4 on: September 14, 2012, 11:15:43 PM »
no segments they are even connected to the same switch.
pineapp is also set to MTU 1500/
unfortunatly the console becomes non responsive (all though ping to the sme server returns ok) and ssh is also unavailable.(only hard reset using the servers power button works)
I did not check the quota for I had many users reach their quota limit many times before, though never had problems even with quota limit full.
I will try to see next time it happens if all recipients have quota space.
(is it possible quota makes the server crash in such a way?)
I will also try to reduce the server's MTU to 1400 to see if it solves it as I saw in the link you sent me ... and by the way my server does give the "too many connections" message when the hang occurs.
Thank you very much for your help I'll post here the results.

Offline mmccarn

  • *
  • 2,626
  • +10/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #5 on: September 15, 2012, 04:26:55 PM »
If possible, I'd recommend testing the ram on the SME server -- it's hard to imagine a purely email-related problem causing the console and ssh to freeze.

I believe there's a memory test option on the SME boot CD.

Offline CharlieBrady

  • *
  • 6,918
  • +3/-0
Re: Sme 7.6 hang (crash) on large mail.
« Reply #6 on: September 17, 2012, 03:17:21 PM »
at first I tried to enable more concurrent sessions (its set to 250 now) from same ip (i tought that might couse the problem) but still the hang happens.

If you have a congestion or memory footprint problem, increasing concurrency will make it worse, not better. Set concurrency back to default, or even to 1, while you debug this problem.