yet more trouble with daemontools and supervise
Hello, gentlemen: I've looked in the archives for this little issue. Lots of people report it, but I *think* I've got my system correctly configured. A couple of problems: my /var/log/maillog fills up with stuff like this: Jun 12 14:09:12 hotcube qmail: 992376552.411296 end msg 1005715 Jun 12 14:09:12 hotcube qmail: 992376552.507199 new msg 1005716 Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 Jun 12 14:09:12 hotcube qmail: 992376552.573170 end msg 1005716 Jun 12 14:09:12 hotcube qmail: 992376552.660653 new msg 1005715 Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 Jun 12 14:09:12 hotcube qmail: 992376552.732709 end msg 1005715 Jun 12 14:09:12 hotcube qmail: 992376552.815510 new msg 1005716 Jun 12 14:09:12 hotcube qmail: 992376552.815629 info msg 1005716: bytes 266 from <[EMAIL PROTECTED]> qp 27416 uid 502 Jun 12 14:09:12 hotcube qmail: 992376552.873183 end msg 1005716 Jun 12 14:09:42 hotcube qmail: 992376582.938896 new msg 1005715 Jun 12 14:09:42 hotcube qmail: 992376582.939013 info msg 1005715: bytes 266 from <[EMAIL PROTECTED]> qp 27450 uid 502 Jun 12 14:09:42 hotcube qmail: 992376582.981100 end msg 1005715 Jun 12 14:09:43 hotcube qmail: 992376583.097289 new msg 1005716 and so on, and so on, and so on. It goes back months like this (I would never have noticed it had it not been for some other issues I was working on). Is this normal? My other qmail installations don't do that. The queue is empty. Then, there's this: [root@hotcube qmail]# /etc/rc.d/init.d/qmail stat qmail-send: up (pid 27564) qmail-smtpd: up (pid 27566) qmail-send/log: unable to open supervise/ok: file does not exist qmail-smtpd/log: unable to open supervise/ok: file does not exist Okay. So I checked for sticky bits on the appropriate directories: [root@hotcube supervise]# ls -ld /var/qmail/supervise/* 927870 drwxr-xr-t4 root qmail1024 Sep 1 2000 /var/qmail/supervise/qmail-send/ 712830 drwxr-xr-t4 root qmail1024 Dec 18 10:27 /var/qmail/supervise/qmail-smtpd/ [root@hotcube supervise]# It looks like I have all the files I need... qmail-send: total 3 1120382 drwxr-xr-t2 root qmail1024 Sep 1 2000 log/ 927871 -rwxr-xr-x1 root qmail 29 Sep 1 2000 run* 497666 drwx--2 root qmail1024 Jun 12 14:19 supervise/ qmail-send/log: total 1 1120383 -rwxr-xr-x1 root qmail 88 Sep 1 2000 run* qmail-send/supervise: total 1 497791 prw---1 root qmail 0 Jun 12 14:19 control| 497667 -rw---1 root qmail 0 Sep 1 2000 lock 497793 prw---1 root qmail 0 Sep 1 2000 ok| 497805 -rw-r--r--1 root root 18 Jun 12 14:19 status qmail-smtpd: total 4 733310 drwxr-xr-t2 root qmail1024 Sep 1 2000 log/ 712915 -rwxr-xr-x1 root qmail 246 Dec 18 10:27 run* 712831 -rwxr-xr-x1 root qmail 240 Sep 1 2000 run~* 667722 drwx--2 root qmail1024 Jun 12 14:19 supervise/ qmail-smtpd/log: total 1 733311 -rwxr-xr-x1 root qmail 94 Sep 1 2000 run* qmail-smtpd/supervise: total 1 667729 prw---1 root qmail 0 Jun 12 14:19 control| 667728 -rw---1 root qmail 0 Sep 1 2000 lock 667731 prw---1 root qmail 0 Sep 1 2000 ok| 667723 -rw-r--r--1 root root 18 Jun 12 14:19 status /var/qmail/supervise/qmail-send/run contains: #!/bin/sh exec /var/qmail/rc and /var/qmail/supervise/qmail-smtpd/run contains: #!/bin/sh QMAILDUID=`id -u qmaild` NOFILESGID=`id -g qmaild` exec /usr/local/bin/softlimit -m 200 \ /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb \ -u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd 2>&1 *catches breath* So... what is going on here? Everything seems to be in order, but if it isn't working properly I'm sure I've missed something. What is it? -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> writes: > qmail-send/log: unable to open supervise/ok: file does not exist There is no need for qmail-send/log. qmail-send starts up the logger by itself as given on it's command line. See /var/qmail/rc. Seems that you simply messed up the logging. What do you have in /var/qmail/rc, and in the run file for qmail-smtpd/log? Regards, Frank
Re: yet more trouble with daemontools and supervise
Frank Tegtmeyer <[EMAIL PROTECTED]> wrote: >Stephen Bosch <[EMAIL PROTECTED]> writes: > >> qmail-send/log: unable to open supervise/ok: file does not exist > >There is no need for qmail-send/log. Sure there is, if you want the logging supervised. >qmail-send starts up the logger >by itself as given on it's command line. See /var/qmail/rc. This is the old-fashioned way to log. -Dave
Re: yet more trouble with daemontools and supervise
Frank Tegtmeyer wrote: > > Stephen Bosch <[EMAIL PROTECTED]> writes: > > > qmail-send/log: unable to open supervise/ok: file does not exist > > There is no need for qmail-send/log. qmail-send starts up the logger > by itself as given on it's command line. See /var/qmail/rc. > > Seems that you simply messed up the logging. What do you have in > /var/qmail/rc, and in the run file for qmail-smtpd/log? Okay, here is what I have in /var/qmail/rc: #!/bin/sh # Using splogger to send the log through syslog. # Using procmail to deliver messages to /var/spool/mail/$USER by default. exec env - PATH="/var/qmail/bin:$PATH" \ qmail-start '|preline procmail' splogger qmail The run file for qmail-smtpd/log contains: #!/bin/sh QMAILDUID=`id -u qmaild` NOFILESGID=`id -g qmaild` exec /usr/local/bin/softlimit -m 200 \ /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb \ -u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd 2>&1 Hope you can help. Thanks, Stephen
Re: yet more trouble with daemontools and supervise
Dave Sill wrote: > > Frank Tegtmeyer <[EMAIL PROTECTED]> wrote: > > >Stephen Bosch <[EMAIL PROTECTED]> writes: > > > >> qmail-send/log: unable to open supervise/ok: file does not exist > > > >There is no need for qmail-send/log. > > Sure there is, if you want the logging supervised. > > >qmail-send starts up the logger > >by itself as given on it's command line. See /var/qmail/rc. > > This is the old-fashioned way to log. But Dave... what's wrong with my setup? =) Should I just reconfigure everything according to the new LWQ? Why do that if everything is otherwise working? I don't have the overview here -- this supervise logging stuff is really opaque for me. -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch writes: > > This is the old-fashioned way to log. > > But Dave... what's wrong with my setup? =) splogger is slow. It's incompatible between systems. > Should I just reconfigure everything according to the new LWQ? Yes. That's the first thing I do when I get to a new customer's site. That way, once I leave them, they can ask questions on the mailing list, and everybody will know where their files are. > I don't have the overview here -- this supervise logging stuff is > really opaque for me. svscan looks in /service for directories with a "run" file. svscan starts up a supervise which runs the run file. Oh, but before doing that, if the directory has the sticky bit set, svscan runs a supervise on ./log/run, and redirects its stdin from the output of the main supervise. So, every service with logging has its current log in /service/*/log/main/current . Maybe I've gone a bit overboard on /service, but here's my listing of services: axfrdns dnscache ftpd msql2dqmail rsyncdsshd bray etrn httpd pop3d qmtpd smtpd tinydns -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | #exclude Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: >Okay, here is what I have in /var/qmail/rc: > >#!/bin/sh > ># Using splogger to send the log through syslog. ># Using procmail to deliver messages to /var/spool/mail/$USER by >default. > >exec env - PATH="/var/qmail/bin:$PATH" \ >qmail-start '|preline procmail' splogger qmail Logging via splogger (syslog). >The run file for qmail-smtpd/log contains: > >#!/bin/sh >QMAILDUID=`id -u qmaild` >NOFILESGID=`id -g qmaild` >exec /usr/local/bin/softlimit -m 200 \ >/usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb \ >-u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd >2>&1 Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run. -Dave
Re: yet more trouble with daemontools and supervise
Dave Sill wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > >Okay, here is what I have in /var/qmail/rc: > > > >#!/bin/sh > > > ># Using splogger to send the log through syslog. > ># Using procmail to deliver messages to /var/spool/mail/$USER by > >default. > > > >exec env - PATH="/var/qmail/bin:$PATH" \ > >qmail-start '|preline procmail' splogger qmail > > Logging via splogger (syslog). Which is deprecated in LWQ, now, correct? Boy -- it's obviously been a while since I configured this machine. It ran so well... I never had to do anything to it. At least, I thought I didn't. Maybe I did and didn't realize it. > >The run file for qmail-smtpd/log contains: > > > >#!/bin/sh > >QMAILDUID=`id -u qmaild` > >NOFILESGID=`id -g qmaild` > >exec /usr/local/bin/softlimit -m 200 \ > >/usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb \ > >-u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd > >2>&1 > > Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run. D'oh! #!/bin/sh exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /var/log/qmail/smtpd -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: >Dave Sill wrote: >> >> Logging via splogger (syslog). > >Which is deprecated in LWQ, now, correct? Yes. >> Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run. > >D'oh! > >#!/bin/sh >exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t >/var/log/qmail/smtpd OK, now refresh my memory...what was the problem? And is that command all on one line? -Dave
Re: yet more trouble with daemontools and supervise
Dave Sill wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > >Dave Sill wrote: > >> > >> Logging via splogger (syslog). > > > >Which is deprecated in LWQ, now, correct? > > Yes. > > >> Sure that's qmail-smtpd/log/run? Looks more like qmail-smtpd/run. > > > >D'oh! > > > >#!/bin/sh > >exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t > >/var/log/qmail/smtpd > > OK, now refresh my memory...what was the problem? And is that command > all on one line? Well, my logs are filling up with garbage (and I get that silly "file does not exist" error when I run qmail stat), and yes, that command was all on one line. -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: >Well, my logs are filling up with garbage Garbage or log entries? Sample, please? >(and I get that silly "file >does not exist" error when I run qmail stat) Sample? -Dave
Re: yet more trouble with daemontools and supervise
Hello... Dave Sill wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > >Well, my logs are filling up with garbage > > Garbage or log entries? Sample, please? Sorry -- it's just that I quoted it at great length before... okay, I'll get it. Stephen Bosch wrote: > > Hello, gentlemen: > > I've looked in the archives for this little issue. Lots of people report > it, but I *think* I've got my system correctly configured. > > A couple of problems: > > my /var/log/maillog fills up with stuff like this: > > Jun 12 14:09:12 hotcube qmail: 992376552.411296 end msg 1005715 > Jun 12 14:09:12 hotcube qmail: 992376552.507199 new msg 1005716 > Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes > 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 > Jun 12 14:09:12 hotcube qmail: 992376552.573170 end msg 1005716 > Jun 12 14:09:12 hotcube qmail: 992376552.660653 new msg 1005715 > Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes > 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 > Jun 12 14:09:12 hotcube qmail: 992376552.732709 end msg 1005715 > Jun 12 14:09:12 hotcube qmail: 992376552.815510 new msg 1005716 > Jun 12 14:09:12 hotcube qmail: 992376552.815629 info msg 1005716: bytes > 266 from <[EMAIL PROTECTED]> qp 27416 uid 502 > Jun 12 14:09:12 hotcube qmail: 992376552.873183 end msg 1005716 > Jun 12 14:09:42 hotcube qmail: 992376582.938896 new msg 1005715 > Jun 12 14:09:42 hotcube qmail: 992376582.939013 info msg 1005715: bytes > 266 from <[EMAIL PROTECTED]> qp 27450 uid 502 > Jun 12 14:09:42 hotcube qmail: 992376582.981100 end msg 1005715 > Jun 12 14:09:43 hotcube qmail: 992376583.097289 new msg > 1005716 > > and so on, and so on, and so on. It goes back months like this (I would > never have noticed it had it not been for some other issues I was > working on). Is this normal? My other qmail installations don't do that. > > The queue is empty. > > Then, there's this: > > [root@hotcube qmail]# /etc/rc.d/init.d/qmail stat > qmail-send: up (pid 27564) > qmail-smtpd: up (pid 27566) > qmail-send/log: unable to open supervise/ok: file does not exist > qmail-smtpd/log: unable to open supervise/ok: file does not exist > > Okay. So I checked for sticky bits on the appropriate directories: > > [root@hotcube supervise]# ls -ld /var/qmail/supervise/* > 927870 drwxr-xr-t4 root qmail1024 Sep 1 2000 > /var/qmail/supervise/qmail-send/ > 712830 drwxr-xr-t4 root qmail1024 Dec 18 10:27 > /var/qmail/supervise/qmail-smtpd/ > [root@hotcube supervise]# > > It looks like I have all the files I need... > > qmail-send: > total 3 > 1120382 drwxr-xr-t2 root qmail1024 Sep 1 2000 log/ > 927871 -rwxr-xr-x1 root qmail 29 Sep 1 2000 run* > 497666 drwx--2 root qmail1024 Jun 12 14:19 > supervise/ > > qmail-send/log: > total 1 > 1120383 -rwxr-xr-x1 root qmail 88 Sep 1 2000 run* > > qmail-send/supervise: > total 1 > 497791 prw---1 root qmail 0 Jun 12 14:19 control| > 497667 -rw---1 root qmail 0 Sep 1 2000 lock > 497793 prw---1 root qmail 0 Sep 1 2000 ok| > 497805 -rw-r--r--1 root root 18 Jun 12 14:19 status > > qmail-smtpd: > total 4 > 733310 drwxr-xr-t2 root qmail1024 Sep 1 2000 log/ > 712915 -rwxr-xr-x1 root qmail 246 Dec 18 10:27 run* > 712831 -rwxr-xr-x1 root qmail 240 Sep 1 2000 run~* > 667722 drwx--2 root qmail1024 Jun 12 14:19 > supervise/ > > qmail-smtpd/log: > total 1 > 733311 -rwxr-xr-x1 root qmail 94 Sep 1 2000 run* > > qmail-smtpd/supervise: > total 1 > 667729 prw---1 root qmail 0 Jun 12 14:19 control| > 667728 -rw---1 root qmail 0 Sep 1 2000 lock > 667731 prw---1 root qmail 0 Sep 1 2000 ok| > 667723 -rw-r--r--1 root root 18 Jun 12 14:19 status > > /var/qmail/supervise/qmail-send/run contains: > > #!/bin/sh > exec /var/qmail/rc > > and /var/qmail/supervise/qmail-smtpd/run contains: > > #!/bin/sh > QMAILDUID=`id -u qmaild` > NOFILESGID=`id -g qmaild` > exec /usr/local/bin/softlimit -m 200 \ > /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb \ > -u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd > 2>&1 There you have it, in all its ugliness. -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: >> my /var/log/maillog fills up with stuff like this: >> >> Jun 12 14:09:12 hotcube qmail: 992376552.411296 end msg 1005715 >> Jun 12 14:09:12 hotcube qmail: 992376552.507199 new msg 1005716 >> Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes >> 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 >> Jun 12 14:09:12 hotcube qmail: 992376552.573170 end msg 1005716 >> Jun 12 14:09:12 hotcube qmail: 992376552.660653 new msg 1005715 >> Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes >> 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 >> Jun 12 14:09:12 hotcube qmail: 992376552.732709 end msg 1005715 >> >> and so on, and so on, and so on. It goes back months like this (I would >> never have noticed it had it not been for some other issues I was >> working on). Is this normal? My other qmail installations don't do that. It's normal for qmail-send to log its actions. It's not normal to see messages "end" without a delivery being logged, or for no "status:" messages to be logged. It's not normal to have a qmail-send/log service when you're logging via splogger/syslog. >> [root@hotcube qmail]# /etc/rc.d/init.d/qmail stat >> qmail-send: up (pid 27564) >> qmail-smtpd: up (pid 27566) >> qmail-send/log: unable to open supervise/ok: file does not exist >> qmail-smtpd/log: unable to open supervise/ok: file does not exist That means supervise isn't running for the log services. >> Okay. So I checked for sticky bits on the appropriate directories: >> >> [root@hotcube supervise]# ls -ld /var/qmail/supervise/* >> 927870 drwxr-xr-t4 root qmail1024 Sep 1 2000 >> /var/qmail/supervise/qmail-send/ >> 712830 drwxr-xr-t4 root qmail1024 Dec 18 10:27 >> /var/qmail/supervise/qmail-smtpd/ Were they set when the services were started? >> qmail-smtpd/log: >> 733311 -rwxr-xr-x1 root qmail 94 Sep 1 2000 run* No "supervise" directory... Further evidence that supervise isn't running. -Dave
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: > Dave Sill wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > > > >Well, my logs are filling up with garbage > > > > Garbage or log entries? Sample, please? > > Sorry -- it's just that I quoted it at great length before... [...] > > Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes > > 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 > > Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes > > 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 > > Jun 12 14:09:12 hotcube qmail: 992376552.815629 info msg 1005716: bytes > > 266 from <[EMAIL PROTECTED]> qp 27416 uid 502 > > Jun 12 14:09:42 hotcube qmail: 992376582.939013 info msg 1005715: bytes > > 266 from <[EMAIL PROTECTED]> qp 27450 uid 502 Each of those messages has a different qmail-queue PID. From this, you can deduce that the sender is connecting to your server, sending the message, and somehow disconnecting or misinterpreting qmail's response to the DATA command. The sender thinks the delivery failed, so it tries again, and again, ad infinitum. Capture one of the messages' SMTP conversation using recordio. That should tell you exactly how the sender's MTA is broken. You can then inform postmaster at that domain. Or block their IP address from connecting to your SMTP daemon. You choice. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: yet more trouble with daemontools and supervise
Charles Cazabon wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > Dave Sill wrote: > > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > > > > > >Well, my logs are filling up with garbage > > > > > > Garbage or log entries? Sample, please? > > > > Sorry -- it's just that I quoted it at great length before... > [...] > > > Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes > > > 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 > > > Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes > > > 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 > > > Jun 12 14:09:12 hotcube qmail: 992376552.815629 info msg 1005716: bytes > > > 266 from <[EMAIL PROTECTED]> qp 27416 uid 502 > > > Jun 12 14:09:42 hotcube qmail: 992376582.939013 info msg 1005715: bytes > > > 266 from <[EMAIL PROTECTED]> qp 27450 uid 502 > > Each of those messages has a different qmail-queue PID. From this, you can > deduce that the sender is connecting to your server, sending the message, > and somehow disconnecting or misinterpreting qmail's response to the DATA > command. The sender thinks the delivery failed, so it tries again, and again, > ad infinitum. > > Capture one of the messages' SMTP conversation using recordio. That should > tell you exactly how the sender's MTA is broken. You can then inform > postmaster at that domain. What's the syntax for that? Does it come with a man page? > Or block their IP address from connecting to your SMTP daemon. You choice. That would mean I would be blocking myself - that "from" information indicates a local user. Is this really what's happening? I am beginning to worry that something is majorly misconfigured here... but the server works perfectly! All the mail that is sent arrives, nobody has problems sending out... *bangs head* So... if the queue is empty, this log stuff indicates that something is repeatedly trying to send. If it's a local user, then... could it be a broken application? Oh boy. -Stephen-
Re: yet more trouble with daemontools and supervise
Hullo again... Dave Sill wrote: > > Stephen Bosch <[EMAIL PROTECTED]> wrote: > > >> my /var/log/maillog fills up with stuff like this: > >> > >> Jun 12 14:09:12 hotcube qmail: 992376552.411296 end msg 1005715 > >> Jun 12 14:09:12 hotcube qmail: 992376552.507199 new msg 1005716 > >> Jun 12 14:09:12 hotcube qmail: 992376552.507323 info msg 1005716: bytes > >> 266 from <[EMAIL PROTECTED]> qp 27390 uid 502 > >> Jun 12 14:09:12 hotcube qmail: 992376552.573170 end msg 1005716 > >> Jun 12 14:09:12 hotcube qmail: 992376552.660653 new msg 1005715 > >> Jun 12 14:09:12 hotcube qmail: 992376552.660776 info msg 1005715: bytes > >> 266 from <[EMAIL PROTECTED]> qp 27403 uid 502 > >> Jun 12 14:09:12 hotcube qmail: 992376552.732709 end msg 1005715 > >> > >> and so on, and so on, and so on. It goes back months like this (I would > >> never have noticed it had it not been for some other issues I was > >> working on). Is this normal? My other qmail installations don't do that. > > It's normal for qmail-send to log its actions. It's not normal to see > messages "end" without a delivery being logged, or for no "status:" > messages to be logged. So, is Charles right? Does this indicate somebody is reattempting delivery? > It's not normal to have a qmail-send/log > service when you're logging via splogger/syslog. > > >> [root@hotcube qmail]# /etc/rc.d/init.d/qmail stat > >> qmail-send: up (pid 27564) > >> qmail-smtpd: up (pid 27566) > >> qmail-send/log: unable to open supervise/ok: file does not exist > >> qmail-smtpd/log: unable to open supervise/ok: file does not exist > > That means supervise isn't running for the log services. > > >> Okay. So I checked for sticky bits on the appropriate directories: > >> > >> [root@hotcube supervise]# ls -ld /var/qmail/supervise/* > >> 927870 drwxr-xr-t4 root qmail1024 Sep 1 2000 > >> /var/qmail/supervise/qmail-send/ > >> 712830 drwxr-xr-t4 root qmail1024 Dec 18 10:27 > >> /var/qmail/supervise/qmail-smtpd/ > > Were they set when the services were started? Yes. I've started and stopped them numerous times to no avail. At least, I have started and stopped them using the /etc/rc.d/init.d/qmail script you provided (at the time) in LWQ. It all seems to work, except for this peculiar problem above. > >> qmail-smtpd/log: > >> 733311 -rwxr-xr-x1 root qmail 94 Sep 1 2000 run* > > No "supervise" directory... Further evidence that supervise isn't > running. *rattles head* So... okay... where is supervise invoked again? I need to eat something... Your suggestion to migrate to the new LWQ setup is looking more appealing by the minute. -Stephen-
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: > > > > Each of those messages has a different qmail-queue PID. From this, you > > can deduce that the sender is connecting to your server, sending the > > message, and somehow disconnecting or misinterpreting qmail's response to > > the DATA command. The sender thinks the delivery failed, so it tries > > again, and again, ad infinitum. > > > > Capture one of the messages' SMTP conversation using recordio. That > > should tell you exactly how the sender's MTA is broken. You can then > > inform postmaster at that domain. > > What's the syntax for that? Does it come with a man page? Yes. It's in Dan's ucspi-tcp package, along with tcpserver et al. Basically you stick it in-between tcpserver and the program which tcpserver would normally run. However, this is assuming these messages are arriving via qmail-smtpd. Based on your comments below, I'm not sure that's the case. > > Or block their IP address from connecting to your SMTP daemon. You > > choice. > > That would mean I would be blocking myself - that "from" information > indicates a local user. Okay, I couldn't determine that from the log snippet; I thought it was an SMTP injection. It might still be, if it's a program which normally sends mail via SMTP instead of /usr/sbin/sendmail or friends. Can you identify the user/process which is sending this mail? > Is this really what's happening? I am beginning to worry that something > is majorly misconfigured here... but the server works perfectly! All the > mail that is sent arrives, nobody has problems sending out... Do you by chance have a mail loop created by a bogus entry in smtproutes? > *bangs head* > > So... if the queue is empty, this log stuff indicates that something is > repeatedly trying to send. If it's a local user, then... could it be a > broken application? Oh boy. It could be a broken application. I haven't seen enough details to tell. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: yet more trouble with daemontools and supervise
Stephen Bosch <[EMAIL PROTECTED]> wrote: >So, is Charles right? He knows a thing or two about qmail... >Does this indicate somebody is reattempting delivery? Looks like it to me. >> No "supervise" directory... Further evidence that supervise isn't >> running. > >*rattles head* > >So... okay... where is supervise invoked again? I need to eat >something... In all versions of LWQ, supervise is started by svscan. In older versions, svscan was run from the "qmail" script on /var/qmail/supervise. In the current LWQ, it's run at boot by init or rc.local on /service. If the top level service directory has the sticky bit set--which you've verified--svscan will also start a supervise for the service's log/run script. You might try doing: qmail stop cd /var/qmail/supervise env - PATH="$PATH" svscan & To see if svscan is giving any errors. You could also insert strace/truss/trace/par--whatever your system call tracing utility is called--into the svscan invocation in the qmail script, e.g.: env - PATH="$PATH" strace -o /var/log/svscan.log svscan & But making sense of the output might not be easy. >Your suggestion to migrate to the new LWQ setup is looking more >appealing by the minute. I don't remember suggesting that, but it's not a bad idea. -Dave
