"cpio: rename failed - Is a directory" on cron yum job

[zephyran]

I've just started at a company running a few Linux servers. One in particular, running Red Hat Enterprise, has a daily cron job running yum update. I'm somewhat new to Linux, though I do have some practical experience with it.

The updates seem to run successfully, but every night the following error appears in the cron job log:

"/etc/cron.daily/yum.cron:

error: unpacking of archive failed on file /etc/httpd/logs: cpio: rename failed - Is a directory"

The person who originally set this server up is no longer with the company, so we're not 100% sure what he did. My department has been looking into this for a while, and here is the best (that we can tell) advice they've received:

"I think the default is for the package to install /etc/httpd/logs as a symlink to /var/log/httpd/. If you've changed /etc/httpd/logs to be a real directory, that would be why the package is complaining. If that's the case, try reverting it to a symlink, and then doing a yum update."

If this is indeed the correct advice, how can I check to see if this is the case, and how can I revert the directory to a symlink?

 

[QatQat]

if he has converted a symlink to a hardlink you can still copy your /var/log/httpd elsewhere, (that would create another hardlink) delete the hardlink and move files back into /var/log/httpd.

After that, re-create a symbolic link again.

QatQat



Life is what happens when you are making other plans.

 

[zephyran]

Ok. How do I do that (which config file, etc.)? I'm still pretty new to Linux, so not quite up to that level yet

 

[zephyran]

I figured this out and, after backing up the existing directory and symlink, switched them around. While that seemed to solve this problem, it caused another: we run RequestTracker on the server, which uses fastCGI, and the "proper" setup breaks it. That explains why the earlier admin swapped the roles in the first place.

I've looked up how to solve the problem with RT, including chmodding the symlink /etc/httpd/logs to 777, but nothing helped.

Does anyone have experience with fastCGI and/or RequestTracker that can offer advice on this issue?