upcp still running longer than 6 hours

[cooty]

For the last week now we're receiving this message every morning "/usr/local/cpanel/scripts/upcp was detected to be running as pid '<number>'. Because it has been running for longer than 6 hours, the process will be killed and a new upcp will be run in it's place."

I assume there's a problem with upcp, what can we do to resolve this?

 

[cPanelMichael]

Hello

You can find the cPanel update logs in the following location:

/var/cpanel/updatelogs

I suggest viewing the most recent log files in the above directory to see if the update is stopping at a specific process.

Thank you.

 

[cooty]

Hi Michael
Thanks for your reply.
The log is full of a single message repeated over and over:
[20111214.231932] [31781] The other application is: PackageKit
[20111214.231932] [31781] Memory : 47 M RSS (505 MB VSZ)
[20111214.231932] [31781] Started: Sat Dec 10 22:22:45 2011 - 4 day(s) 0:56:47 ago
[20111214.231932] [31781] State : Sleeping, pid: 3459
[20111214.231934] [31781] Another app is currently holding the yum lock; waiting for it to exit...

Ta Dave

 

[cPanelTristan]

What process is holding a lock on yum?

ps aux | grep yum

 

[cooty]

# ps aux | grep yum
root 3459 0.0 2.3 517544 48356 ? S Dec10 0:02 /usr/bin/python /usr/share/PackageKit/helpers/yum/yumBackend.py get-packages unknown
root 17450 0.0 0.9 221712 18668 ? S Dec18 1:01 /usr/bin/python /usr/bin/yum -y update
root 22332 0.0 0.9 221716 18660 ? S Dec13 7:19 /usr/bin/python /usr/bin/yum -y update

 

[cPanelTristan]

Please kill these processes as they aren't allowing yum to update:

kill -9 3459
kill -9 17450
kill -9 22332

After that, please try to run the following:

yum -y update

If that hangs, please let us know it is hanging and/or the error message you receive.

 

[storminternet]

Also check /etc/resolv.conf and make sure that you have added correct IP. Sometimes incorrect resolver configuration
would also cause such issues.

 

[cPanelTristan]

Also check /etc/resolv.conf and make sure that you have added correct IP. Sometimes incorrect resolver configuration
would also cause such issues.

While it is helpful to point this out, unfortunately the details provided are far too broad in indicating what /etc/resolv.conf should contain. For people who do not know how /etc/resolv.conf should be configured, they might mistakenly put in their server's IP address or localhost, both which aren't valid for the resolver. It would be better to either link to another forum thread where this has been discussed or to be specific when mentioning this information.

As such, here is a forum thread where specifics were discussed:

http://forums.cpanel.net/f185/ipche...esomekindofaddress-com-233542.html#post962301

 

[storminternet]

Ahh that's right. I should have explained about the resolv.conf and correct IP to put into it.
Thank you Tristan for pointing me about it.

 

[cooty]

Thanks all
The server got into a mess with one of the killed processes showing as <defunct>. The output of the ps aux command changed with a large amount of text. I decided that a server restart was the best way forward. I have a lot of experience with resolv.conf and think this is OK, DNS lookups are fine.
The server restart seems to have resolved the issue for now, hopefully it will stay that way.