Problems with mmdf / uucp and lock file - SCO

This is a discussion on Problems with mmdf / uucp and lock file - SCO ; I am working on SCO open server 5.0.5 We are having issues with our file systems every now and then and I think it has something do with the file /usr/spool/mail/root.lock hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Problems with mmdf / uucp and lock file

  1. Problems with mmdf / uucp and lock file

    I am working on SCO open server 5.0.5

    We are having issues with our file systems every now and then and I
    think it has something do with the file /usr/spool/mail/root.lock
    hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    thousands of files.

    Problem seems to stem back to a cron job: 45 23 * * * ulimit 5000; /
    usr/lib/uucp/uudemon.clean > /dev/null

    Not sure why but at some point running this seems to leave the
    root.lock file. The only thing in that script I can see that would do
    anything with the /usr/spool/ files is this command: uuclean -D7 -C7 -
    X2 -o2 -W1

    I can't seem to make the connection of the uuclean command and the
    root.lock being left around. I am basing most of this off of time
    stamps and the first message left(same time stamp as root.lock) in /
    usr/spool/mmdf/lock/home/msg/

    In today's world we are basically taking care of the issue by doing
    the following:
    cd /usr/spool/mmdf/lock/home
    /etc/rc2.d/P86mmdf stop
    rm -r *
    chown mmdf:mmdf *
    chmod 777 *
    cd /usr/spool/mail
    rm *.lock
    /etc/rc2.d/P86mmdf start


    I know this could be solved with a simple cron job to do some extra
    clean up work but I don't feel like that's a good solution and I am
    hoping to get some understanding of why the root.lock file is not
    being removed. I have found some but very little about this issue on
    the net so far(with most SCO problems) and what I listed above is
    exactly the same thing we have been doing for years now.

    Thanks,
    -Mike

  2. Re: Problems with mmdf / uucp and lock file

    imp 7 wrote:
    > I am working on SCO open server 5.0.5
    >
    > We are having issues with our file systems every now and then and I
    > think it has something do with the file /usr/spool/mail/root.lock
    > hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    > thousands of files.


    Throw MMDF *OUT*, if at all possible. Proceed directly to sendmail. No one
    else but SCO uses MMDF, and given the age of your OS, you're not going to get
    significant advances for it.

    And why are you running 5.0.5? The expense of cleaning up after debris like
    this could potentially be applied to a clean upgrade to 5.0.7, which is
    similar enough to hopefully avoid needing to recompile your own tools but is
    overall a much better environment than even 5.0.6.

  3. Re: Problems with mmdf / uucp and lock file

    Nico Kadel-Garcia wrote:
    > imp 7 wrote:
    >> I am working on SCO open server 5.0.5
    >>
    >> We are having issues with our file systems every now and then and I
    >> think it has something do with the file /usr/spool/mail/root.lock
    >> hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    >> thousands of files.

    >
    > Throw MMDF *OUT*, if at all possible. Proceed directly to sendmail. No
    > one else but SCO uses MMDF, and given the age of your OS, you're not
    > going to get significant advances for it.
    >
    > And why are you running 5.0.5? The expense of cleaning up after debris
    > like this could potentially be applied to a clean upgrade to 5.0.7,
    > which is similar enough to hopefully avoid needing to recompile your own
    > tools but is overall a much better environment than even 5.0.6.


    Nore: I'm sorry if I sound harsh here, but I've been down this road recently,
    and still want to throw out MMDF.

  4. Re: Problems with mmdf / uucp and lock file

    Mike,

    imp 7 wrote:
    > I am working on SCO open server 5.0.5
    >
    > We are having issues with our file systems every now and then and I
    > think it has something do with the file /usr/spool/mail/root.lock
    > hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    > thousands of files.
    >
    > Problem seems to stem back to a cron job: 45 23 * * * ulimit 5000; /
    > usr/lib/uucp/uudemon.clean > /dev/null
    >
    > Not sure why but at some point running this seems to leave the
    > root.lock file. The only thing in that script I can see that would do
    > anything with the /usr/spool/ files is this command: uuclean -D7 -C7 -
    > X2 -o2 -W1
    >
    > I can't seem to make the connection of the uuclean command and the
    > root.lock being left around. I am basing most of this off of time
    > stamps and the first message left(same time stamp as root.lock) in /
    > usr/spool/mmdf/lock/home/msg/
    >
    > In today's world we are basically taking care of the issue by doing
    > the following:
    > cd /usr/spool/mmdf/lock/home
    > /etc/rc2.d/P86mmdf stop
    > rm -r *
    > chown mmdf:mmdf *
    > chmod 777 *
    > cd /usr/spool/mail
    > rm *.lock
    > /etc/rc2.d/P86mmdf start
    >
    >
    > I know this could be solved with a simple cron job to do some extra
    > clean up work but I don't feel like that's a good solution and I am
    > hoping to get some understanding of why the root.lock file is not
    > being removed. I have found some but very little about this issue on
    > the net so far(with most SCO problems) and what I listed above is
    > exactly the same thing we have been doing for years now.
    >
    > Thanks,
    > -Mike


    Switching to Sendmail isn't necessarily bad advice, but you're trading
    one set of problems for another. I would go here and search for
    'mmdf':

    http://wdb1.sco.com/kb/search

    In particular, I have used TA #106039 successfully. It might not
    address your situation specifically but it's a very comprehensive
    tutorial.

    TA #107593 addresses how to switch to sendmail. Or you could install
    a linux or freebsd server with qmail and use it to handle mail.

    Good luck,
    Mark

  5. Re: Problems with mmdf / uucp and lock file

    On Sep 24, 9:20*am, mbennett
    wrote:
    > Mike,
    >
    >
    >
    > imp 7 wrote:
    > > I am working on SCO open server 5.0.5

    >
    > > We are having issues with our file systems every now and then and I
    > > think it has something do with the file /usr/spool/mail/root.lock
    > > hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    > > thousands of files.

    >
    > > Problem seems to stem back to a cron job: *45 23 * * * ulimit 5000; /
    > > usr/lib/uucp/uudemon.clean > /dev/null

    >
    > > Not sure why but at some point running this seems to leave the
    > > root.lock file. *The only thing in that script I can see that would do
    > > anything with the /usr/spool/ files is this command: uuclean -D7 -C7 -
    > > X2 -o2 -W1

    >
    > > I can't seem to make the connection of the uuclean command and the
    > > root.lock being left around. *I am basing most of this off of time
    > > stamps and the first message left(same time stamp as root.lock) *in /
    > > usr/spool/mmdf/lock/home/msg/

    >
    > > In today's world we are basically taking care of the issue by doing
    > > the following:
    > > cd /usr/spool/mmdf/lock/home
    > > /etc/rc2.d/P86mmdf stop
    > > rm -r *
    > > chown mmdf:mmdf *
    > > chmod 777 *
    > > cd /usr/spool/mail
    > > rm *.lock
    > > /etc/rc2.d/P86mmdf start

    >
    > > I know this could be solved with a simple cron job to do some extra
    > > clean up work but I don't feel like that's a good solution and I am
    > > hoping to get some understanding of why the root.lock file is not
    > > being removed. *I have found some but very little about this issue on
    > > the net so far(with most SCO problems) and what I listed above is
    > > exactly the same thing we have been doing for years now.

    >
    > > Thanks,
    > > -Mike

    >
    > Switching to Sendmail isn't necessarily bad advice, but you're trading
    > one set of problems for another. *I would go here and search for
    > 'mmdf':
    >
    > http://wdb1.sco.com/kb/search
    >
    > In particular, I have used TA #106039 successfully. *It might not
    > address your situation specifically but it's a very comprehensive
    > tutorial.
    >
    > TA #107593 addresses how to switch to sendmail. *Or you could install
    > a linux or freebsd server with qmail and use it to handle mail.
    >
    > Good luck,
    > Mark


    Yea, you don't have to tell me to get rid of mmdf. The boss man is
    kind of scared of change.

    These boxs are not email servers, they run an application for our
    retail chain. There is one error report email that is semi-critical
    that leaves these boxs maybe 3 times a year.

    Linux is a road I have been wanting to go down but that will not be
    happening for a while still. Our software vender has only supported
    linux for the past year and we hope to get there at some point.

    Still looking for anyone's thoughts on if uuclean could be part of the
    problem

    Thanks,
    Mike

  6. Re: Problems with mmdf / uucp and lock file

    On Sep 24, 1:41*pm, imp 7 wrote:
    > On Sep 24, 9:20*am, mbennett
    > wrote:
    >
    >
    >
    >
    >
    > > Mike,

    >
    > > imp 7 wrote:
    > > > I am working on SCO open server 5.0.5

    >
    > > > We are having issues with our file systems every now and then and I
    > > > think it has something do with the file /usr/spool/mail/root.lock
    > > > hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    > > > thousands of files.

    >
    > > > Problem seems to stem back to a cron job: *45 23 * * * ulimit 5000;/
    > > > usr/lib/uucp/uudemon.clean > /dev/null

    >
    > > > Not sure why but at some point running this seems to leave the
    > > > root.lock file. *The only thing in that script I can see that woulddo
    > > > anything with the /usr/spool/ files is this command: uuclean -D7 -C7 -
    > > > X2 -o2 -W1

    >
    > > > I can't seem to make the connection of the uuclean command and the
    > > > root.lock being left around. *I am basing most of this off of time
    > > > stamps and the first message left(same time stamp as root.lock) *in/
    > > > usr/spool/mmdf/lock/home/msg/

    >
    > > > In today's world we are basically taking care of the issue by doing
    > > > the following:
    > > > cd /usr/spool/mmdf/lock/home
    > > > /etc/rc2.d/P86mmdf stop
    > > > rm -r *
    > > > chown mmdf:mmdf *
    > > > chmod 777 *
    > > > cd /usr/spool/mail
    > > > rm *.lock
    > > > /etc/rc2.d/P86mmdf start

    >
    > > > I know this could be solved with a simple cron job to do some extra
    > > > clean up work but I don't feel like that's a good solution and I am
    > > > hoping to get some understanding of why the root.lock file is not
    > > > being removed. *I have found some but very little about this issue on
    > > > the net so far(with most SCO problems) and what I listed above is
    > > > exactly the same thing we have been doing for years now.

    >
    > > > Thanks,
    > > > -Mike

    >
    > > Switching to Sendmail isn't necessarily bad advice, but you're trading
    > > one set of problems for another. *I would go here and search for
    > > 'mmdf':

    >
    > >http://wdb1.sco.com/kb/search

    >
    > > In particular, I have used TA #106039 successfully. *It might not
    > > address your situation specifically but it's a very comprehensive
    > > tutorial.

    >
    > > TA #107593 addresses how to switch to sendmail. *Or you could install
    > > a linux or freebsd server with qmail and use it to handle mail.

    >
    > > Good luck,
    > > Mark

    >
    > Yea, you don't have to tell me to get rid of mmdf. *The boss man is
    > kind of scared of change.
    >
    > These boxs are not email servers, they run an application for our
    > retail chain. There is one error report email that is semi-critical
    > that leaves these boxs maybe 3 times a year.
    >
    > Linux is a road I have been wanting to go down but that will not be
    > happening for a while still. *Our software vender has only supported
    > linux for the past year and we hope to get there at some point.
    >
    > Still looking for anyone's thoughts on if uuclean could be part of the
    > problem
    >
    > Thanks,
    > Mike


    Mike,

    I didn't really intend to give an unresponsive reply, so here are some
    things you might try. First, I can see no direct connection between
    uuclean and mmdf, so what is probably happening is that uuclean is
    tripping over another issue when it runs, which leaves the lock file.
    Find and fix that problem and uuclean will run and the lock file issue
    will solve itself.

    When I 'man uuclean' one of the primary responsibilities is:

    "Return mail, which cannot be delivered, to the sender."

    So it's may just a case of a bad address from a sender, and since this
    is only sending a few messages a year it should be pretty easy to
    backtrack.

    I would also bring the system up in single-user mode and run 'fsck -
    ofull' on all filesystems.

    Then run custom | Software | Verify System and check off 'Normal
    system state (Thorough)'. Do not run 'Strict Database Compliance'.
    Fix any problems found.

    Then go here and look through the Troubleshooting MMDF section, which
    is probably going to be the same as with 5.0.5, since mmdf hasn't
    really changed much:
    http://osr507doc.sco.com/en/MailMsgG/CONTENTS.html

    Once you've done that to be sure everything is OK, go back to my first
    email and go through TA #106039 because I'm pretty sure that's where
    the solution to your problem will be found. It really is an excellent
    tutorial.

    Mark

  7. Re: Problems with mmdf / uucp and lock file

    In article <3a11c85c-da62-4b87-9e82-ca5f51ae4afa@d77g2000hsb.googlegroups.com>,
    imp 7 wrote:
    >I am working on SCO open server 5.0.5
    >
    >We are having issues with our file systems every now and then and I
    >think it has something do with the file /usr/spool/mail/root.lock
    >hanging around and causing /usr/spool/mmdf/lock/home/* to fill up with
    >thousands of files.
    >
    >Problem seems to stem back to a cron job: 45 23 * * * ulimit 5000; /
    >usr/lib/uucp/uudemon.clean > /dev/null
    >
    >Not sure why but at some point running this seems to leave the
    >root.lock file. The only thing in that script I can see that would do
    >anything with the /usr/spool/ files is this command: uuclean -D7 -C7 -
    >X2 -o2 -W1
    >
    >I can't seem to make the connection of the uuclean command and the
    >root.lock being left around. I am basing most of this off of time
    >stamps and the first message left(same time stamp as root.lock) in /
    >usr/spool/mmdf/lock/home/msg/


    uudemon.clean sends mail to root. If there is a problem with mail delivery to
    root, the root.lock file is liable to be left behind. If you're periodically
    removing everything under /usr/spool/mmdf/lock/home (including the queue
    directories), it sounds like you don't use/want mail at all on this machine -
    is that the case? Also, do you actually use uucp? If not, step 1 is to
    disable the uudemon.clean cron job and see if you continue to experience
    problems.

    John

    >In today's world we are basically taking care of the issue by doing
    >the following:
    >cd /usr/spool/mmdf/lock/home
    >/etc/rc2.d/P86mmdf stop
    >rm -r *
    >chown mmdf:mmdf *
    >chmod 777 *
    >cd /usr/spool/mail
    >rm *.lock
    >/etc/rc2.d/P86mmdf start
    >
    >
    >I know this could be solved with a simple cron job to do some extra
    >clean up work but I don't feel like that's a good solution and I am
    >hoping to get some understanding of why the root.lock file is not
    >being removed. I have found some but very little about this issue on
    >the net so far(with most SCO problems) and what I listed above is
    >exactly the same thing we have been doing for years now.
    >
    >Thanks,
    >-Mike



    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

+ Reply to Thread