Hi all:

        Well, I've got at last serialmail and AutoTURN installed and working,
following the instruciones in the serialmail package. The only problem
that I have now is that, after triggering an AutoTURN delivery,
maildirsmtp locks the proper directory, sends the messages in it
correctly... but never unlocks the directory (that is, it doesn't delete
the "seriallock" file that it creates). The line that I use to start
serialmail in my startup scripts is:


        /usr/local/bin/tcpserver -c55 -v -x/etc/tcp.smtp.cdb -u 7791 -g 2108 0
smtp /etc/rc.d/rc.qmail-smtpd 2>&1 |/usr/local/bin/accustamp |
/usr/local/bin/setuser root /usr/local/bin/cyclog -n12
/var/log/qmail-receive &


        And "rc.qmail-smtpd", in turn, has:

        /usr/local/qmail/bin/qmail-smtpd 
        cd /usr/local/qmail/autoturn
        exec setlock -nx $TCPREMOTEIP/seriallock \
        maildirsmtp $TCPREMOTEIP autoturn-$TCPREMOTEIP- $TCPREMOTEIP AutoTURN


        The AutoTURN instructions said to include this in the main qmail
startup script with "sh -c '(script here)'", but I couldn't get it to
work properly in any way (specially the part about redirecting errors to
cyclog), so I'm putting them in a separate file.
        Looking at the setlock man pages, I see this:


        Normally the lock disappears when program exits.

       (Here's  the complete story: program is given a descriptor
       for a locked ofile pointing to file.  The lock  disappears
       when  this  ofile  is (1) closed by all the processes that
       have descriptors for it or (2) explicitly unlocked.)


        Which makes me think that maildirsmtp doesn't exit cleanly, but I can't
find it with ps -auxw anywhere in my list of processes. Also, I don't
know what an "ofile" is; I even asked our local Unix guru, who claims
that he has never heard that word before (feel free to tell me if we
need to depose him of his guru status).
        Any ideas? I'm using Slackware 3.2 (with a Linux 2.0.34 kernel) if that
helps. If you need more information, just ask...



                                                Paulo Jan.
                                                DDnet.

Reply via email to