1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice

Qmail stopping

Discussion in 'Plesk for Linux - 8.x and Older' started by xavi, Nov 2, 2005.

  1. xavi

    xavi Guest

    0
     
    Hi everybody,

    I've read some posts about the same problem, but I couldn't solve it yet. Qmail (and, in fact, inetd too) stops periodically. I need to restart the services to accept new smtp connections. I am completely lost. Could anybody help me?

    Plesk: 7.5.4
    OS: Debian sarge 3.1
    ii drweb-qmail 4.32-debian3.1 qmail Mail Transfer Agent
    ii psa-qmail 1.03-debian3.1 qmail Mail Transfer Agent
    ii psa-qmail-rbls 0.70-debian3.1 Antispam DNS-based block lists

    Qmail works fine apparentely:
    Nov 2 13:24:34 ns3 qmail: 1130934274.888835 starting delivery 2123: msg 12730412 to local xxxxx
    Nov 2 13:24:34 ns3 qmail: 1130934274.888863 status: local 1/10 remote 20/20
    Nov 2 13:24:34 ns3 spamd[22202]: got connection over /tmp/spamd_full.sock
    Nov 2 13:24:34 ns3 spamd[22202]: Using default config for xxxxx
    Nov 2 13:24:34 ns3 spamd[22202]: processing message (unknown) for xxxxx:110.
    Nov 2 13:24:34 ns3 spamd[22202]: clean message (0.2/6.0) for xxxxx:110 in 0.1 seconds, 2762 bytes.
    Nov 2 13:24:34 ns3 spamd[22202]: result: . 0 - AWL,HTML_60_70,HTML_MESSAGE,RCVD_BY_IP scantime=0.1,size=2762,mid=(unknown),autolearn=ham
    Nov 2 13:24:35 ns3 qmail: 1130934275.004768 delivery 2123: success: did_1+0+2/did_0+0+1/
    Nov 2 13:24:35 ns3 qmail: 1130934275.005014 status: local 0/10 remote 20/20
    Nov 2 13:24:35 ns3 qmail: 1130934275.005033 end msg 12730412
     
  2. dracoola

    dracoola Guest

    0
     
    i've the same problem.

    qmail is stopping periodicly on my Debian server.

    furthermore i've installed operating system and Plesk CP but still i've same problem
     
  3. jackjoe

    jackjoe Guest

    0
     
    it seems a problem with watchdog or dr.web.
    I had the same problem about 2 weeks and I disable watchdog and dr.web.
    now I have no problems with qmail

    Suse9.1 Pelsk 7.5.4. Patch ...17.14

    Greetings
    Jan
     
  4. dracoola

    dracoola Guest

    0
     
    watchdog already disabled, i've enabled yet.

    maybe there is problem with dr.web.
     
  5. ShadowMan@

    ShadowMan@ Guest

    0
     
    I always recommend uninstalling both Watchdog and DrWeb (not just disabling them). Not sure how to do it on your OS, on other LInux it would be 'rpm -e ...'
     
  6. DaveNET@

    DaveNET@ Guest

    0
     
    Hi.

    What a timely topic. I have the same problem. The SMTP service goes down for 9 minutes at a time. This happens several times per day. I was not aware of this until I subscribed to a port monitoring service. I did notice occasionally that outgoing mail would get stuck in my outbox at times, but then if I waited a few minutes, it would eventually get sent.

    I do not have Dr.Web or Watchdog installed.

    I'm using Debian 3.1 and Plesk 7.5.4.

    David
     
  7. ShadowMan@

    ShadowMan@ Guest

    0
     
    Are you on a VPS/Virtuozzo server, or a dedicated standalone server?

    If you are on a VPS/Virtuozzo, check your cron jobs for one named a1dummy it is a script designed to save on server resources by only running qmail every 10 minutes. Many have gotten rid of this script and reset Qmail to run full time.
     
  8. DaveNET@

    DaveNET@ Guest

    0
     
    I'm on a dedicated server that I own. Maybe one of the other posters has a VPS.

    However on mine, the service seems to recover. Other posters seem to indicate that manual intervention is required. Not in my case. I am not aware of the service outage until I get a notice from the monitoring service and by then it seems to be back up.

    David
     
  9. rommer

    rommer Guest

    0
     
    I also found that the watchdog was causing qmail to stop randomly. I still run the watchdog but removed qmail from the list of things it monitors.

    qmail has not stoped since then on 2 different servers...
     
  10. DaveNET@

    DaveNET@ Guest

    0
     
    Restarting inetd sees to solve the problem. I have had port 25 become inaccesible like 8 times since noon today. It is always down for 9 minutes. This time 5 minutes into the downtime I restarted inetd and port 25 became available again.

    Any ideas what is happening? I would like to solve this.

    David
     
  11. jamesyeeoc

    jamesyeeoc Guest

    0
     
    Googling on 'debian +qmail +inetd' shows some references to the Qmail docs saying that it is better to run qmail under tcpserver instead of inetd on the Debian OS.

    Maybe something for you guys to check into ? I'm a solid RH distro user. (soon to be all CentOS)
     
  12. DaveNET@

    DaveNET@ Guest

    0
     
    Thanks James. I'll check into that. Sounds like hopefully a solution to my problem.

    David
     
  13. DaveNET@

    DaveNET@ Guest

    0
     
    Plesk technicians confirmed the problem between Debian and Qmail. Here's the response I got after they reviewed my log files and my report to them of yesterday's outages on port 25.

    I googled "smtp/tcp server failing (looping), service terminated" and found that this is qmail's and Debian specific issue. Really inetd works with qmail-smtpd via /var/qmail/bin/tcp-env, a program that finds out information about tcp connection, puts the information into several environment variables and runs program with the given arguments. In the debian-user mail-list http://lists.debian.org/debian-user/1999/05/msg01861.html

    I found that tcpserver is recommended for using instead of tcp-env. Suppose that documentations and sources in 'ucspi-tcp-src' package will be useful for you.

    David
     
  14. lgeoffrey

    lgeoffrey Guest

    0
     
    Debian 3.1 / Plesk 7.5.4

    Hello,

    We are having the same problem for weeks.

    We tried:
    - scripts to restart it every minutes
    (reload, stop and start and so on)

    We've contacted SWSoft and got an answer:
    You can do following operations for solving this issue.
    1. add in start script /etc/init.d/qmail following string:
    pidofproc $proccess > /var/run/qmail.pid 2>&1
    2. restart qmail service
    /etc/init.d/stop
    /etc/init.d/start
    3. correct /opt/psa/etc/modules/watchdog/monitrc configuration
    file

    example of monitrc file:

    set daemon 150
    #check host qmail with address localhost
    check process qmail with pidfile /var/run/qmail.pid
    # start = "/opt/psa/admin/bin/mailmng --start-smtpd"
    # stop = "/opt/psa/admin/bin/mailmng --stop-smtpd"
    start = "/etc/init.d/qmail start"
    stop = "/etc/init.d/qmail stop"
    # if failed host localhost port 25 protocol smtp with timeout 5
    if 5 restarts within 5 cycles then timeout

    4. restarted monit service

    We test that "solution" for 2 days and qmails continues to stop.
    I hope there is a way to get rid of that.
    We need to look every hours on the server.

    Any help would be really appreciated.
     
  15. DaveNET@

    DaveNET@ Guest

    0
     
    Hi.

    On our setup, we finally discovered it was not Qmail that was stopping, but the problem was related to inetd, the wrapper that listens on port 25. It would go offline for 9 minutes at a time then come back online by itself.

    Plesk didn't fix it, but one of their technicians got us looking in the right direction. He pointed us to this link, http://lists.debian.org/debian-user/1999/05/msg01861.html

    Well, someone there had come up with a solution and once our techie made the adjustment, we have not had the port 25 go down any more in over 1 days. It seems to be fixed.

    The trick is to edit the inetd.conf file and here's the comment that did the trick for us...

    "The maximum number of connections per second that will be accepted defaults to 40. You may increase that number. You will notice that there is a field that has either wait or nowait. You may add a maximum connection rate to that thusly:

    nowait.<number>

    So nowait.200 would allow 200 connections per second before complaining."

    I hope this might help someone out there.

    David
     
  16. roberto@

    roberto@ Guest

    0
     
    Hi!!

    My inetd conf file is like this,

    ftp stream tcp nowait root /usr/sbin/tcpd in.proftpd
    smtp stream tcp nowait root /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_
    auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
    smtps stream tcp nowait root /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp
    _auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
    poppassd stream tcp nowait/1000 root /usr/sbin/tcpd /opt/psa/admin/bin/poppassd
    -------------

    shall I put something like

    smtp stream tcp nowait.250 root

    for 250 connections??

    please advise
     
  17. kazmen

    kazmen Guest

    0
     
    RE: qmail problem , working solution

    Hello we had the same problems with qmail. The process that name is qmail-send crashed and the messages in qmail-qstat shows that some of e-mail are in preprocesed field.
    We wrote a small and working solution:
    script wroted in shell:
    ---
    #!/bin/bash
    while true; do
    test ! `pidof qmail-send` && /etc/init.d/qmail start >/dev/null 2>&1
    sleep 360
    done
    ---
    save it to a file do:
    chmod +x filename
    and start it
    ./filename &
     
  18. linkz

    linkz Guest

    0
     
    Re: RE: qmail problem , working solution

    Very good man, i dont have a problem, but use your script for other think.
    Thankz

     
  19. hostex

    hostex Guest

    0
     
    We are running FreeBSD 6.1 and also ran into this problem.

    Our fix was to killall inetd and then start it with

    /usr/sbin/inetd -wW -R512 -c256 -C60

    rather than

    /usr/sbin/inetd -wW -C60

    we then edited /etc/defaults/rc.conf so inetd starts with these flags.

    inetd_flags="-wW -R512 -c256 -C60" # Optional flags to inetd

    Please keep these values low and increase as needed during testing (and do not edit rc.conf until you are sure it's ok) since we had the server lock up if they are set too high. Make a backup of rc.conf in case you need to reset to the default.

    If you do a man of inetd you can see how these settings affect inetd.

    - Dave
     
Loading...