On Fri, July 12, 2013 13:34, Alexander Dalloz wrote:
Am 12.07.2013 16:06, schrieb James B. Byrne:
CentOS-6.4_x86_64
I have a KVM virtual machine (several actually) which acts as a warm spare for another kvm instance running on a different physical host. Each hour it backs up the live system using rsync. This morning I discovered that the backup instance was running at 99% utilisation and that the process consuming the entire virtual cpu was this:
sh -c rpm -q -a --queryformat "%{NAME}\n%{VERSION}-%{RELEASE}\n%{EPOCH}\n%{GROUP}\n%{SUMMARY}\n\n" 2>/dev/null
In fact there were two identical instances of these processes, one
. . .
Where is this process started from? What does it do? And why is it consuming so much cpu.?
Does anyone here have any ideas?
rpm-cron-4.8.0-32.el6.noarch
which contains
/etc/cron.daily/rpm
It writes a file which contains a list of installed RPM packages on the system.
Does anyone have any suggestion as why this process would get hung up like this?
Am 13.07.2013 17:02, schrieb James B. Byrne:
On Fri, July 12, 2013 13:34, Alexander Dalloz wrote:
Am 12.07.2013 16:06, schrieb James B. Byrne:
CentOS-6.4_x86_64
I have a KVM virtual machine (several actually) which acts as a warm spare for another kvm instance running on a different physical host. Each hour it backs up the live system using rsync. This morning I discovered that the backup instance was running at 99% utilisation and that the process consuming the entire virtual cpu was this:
sh -c rpm -q -a --queryformat "%{NAME}\n%{VERSION}-%{RELEASE}\n%{EPOCH}\n%{GROUP}\n%{SUMMARY}\n\n" 2>/dev/null
[ ... ]
Does anyone have any suggestion as why this process would get hung up like this?
Probably you had updates installed on the primary VM, then your rsync job did the syncronization while at the same time the rpm job had started on the secondary system, thus the database query (rpm_db is in fact a database) got confused and failed to operate properly. That's to be expected if you work with a database and inject changes to its files with something like rsync.
Alexander
From: James B. Byrne byrnejb@harte-lyne.ca
Does anyone have any suggestion as why this process would get hung up like this?
Next time you find one, maybe try a strace on it to see what it is doing...
JD