I have a strange one here. We're testing out yum-cron and on the systems that have a specific directory and a /etc/my.cnf with the directory name in it, yum-cron will not work from cron.daily - though it does work properly if run by hand - executing /etc/cron.daily/0yum-cron

I have a directory called /mysqldata. This is naturally also in the /etc/my.cnf file. It also lives in LVM meta data under /etc/lvm/ files.

When crond runs the /etc/sysconfig/0yum-cron at night, it will not run successfully and produces an email notification saying.

     "No such command: mysqldata.  Please use /usr/bin/yum --help"

I've cranked up yum-cron debug to level 3, but it did not reveal much to help. I'm going to the level 10 tonight to see what happens.

One note however, in the config file - /etc/sysconfig/yum-cron I have set the exeption parameters to the following:

YUM_PARAMETER="-x kernel* -x glibc* -x mysql* -x httpd* "

I'm changing one of the systems to specifically exclude the mysql packages in hopes it gets past the error. Like so:

YUM_PARAMETER="-x kernel* -x glibc* -x mysql -x mysql-server -x httpd* "

Again, if I run it by hand the error does not occur.

I've checked root's environment settings as well as my own user account and I don't see anything that sticks out as a mysql issue - there's nothing mysql-related in the ENV settings.

This occurs on a system that DOES and DOES NOT have mysql-server and mysql packages installed - meaning, the /mysqldata directory is not necessarily used on all the systems that fail the update - it's simply a left over from a clone.

How could our term "mysqldata" relate or interfere with yum-cron?

Where else can I look. Looking at /var/log/yum.log reveals nothing at all. No updates, no failures.