ESX 3.5.0 Update 2 [cimservera <defunct>]

[dominic7]

Is anyone else getting a tone of defunct processes from cimservera after they install ESX 3.5.0 Update 2?

I've got cluster that is generating a lot of these that was all rebuilt at update 2. Unfortunately the output doesn't format well in here.

[j_dubbs]

You are right. I am seeing failures from HP SIM logging into the host. SIM is setup to use a windows domain account - which obviously won't work on ESX without configuring for LDAP.

I've correlated the number of defunct processes to be the same as the number of failed login attempts in /var/log/messages for a period. I just cleared the defunct processes on all the hosts, and will monitor throughout the day. Looks like the 'fix' to these might be to setup proper monitoring from SIM - or like you said, just remove them.

[MalcO]

It looks as if it is caused by the Daily System Identification task within Systems Insight Manager as the time that this runs corresponds with the entries in the messages file. I have set this task to not be scheduled and will know in approx 1 hour if this has resolved the issue. All other Systems Insight Manager monitoring appears to be operating correctly ie notifying of nic failures, disk usage etc.

[MalcO]

Well no more processes started so looks like this is a solution.

[EPL]

From what I understand this error occurs whether or not you have the management agents installed or not. So the problem is not necessarily only related to VMware, rather HP SIM and VMware. Looking on HP's website there is a SIM 5.2 SP2 hotfix that addresses some problems with ESX (not sure if its at all realted meaning we'll have to do more research). I believe there's a way to supply SIM with a set of credentials to use for discovery. It could be trying to use your domain login and failing, and ESX 3.5 U2 just doesn't handle that very well.

What versions of SIM are all of you running?

I'm 5.1 sp1

[MalcO]

Running 5.2 SP2, also in the earlier version of 3.5 (64607) the failed logins were logged in the messages file but the cimservera processes were not created so the issue was not so serious.

[EPL]

I just modified the credentials on SIM to not use the domain account. I'll continue to monitor and post my findings.

[EPL]

Looks like that did the trick. In SIM if you go to Options, Protocol Settings, System Protocol Settings, select your vm servers, On the next page in the WBEM settings select the Use Values Specified below, and add your username and password.

I'll keep my eye on it throughout the day.

[stormlight]

so this shouldnt be an issue if you just use the agent and do not connect it to a Systems Insight manag server?

If you find this or any post helpful please award points

[EPL]

I think so, because it seems to be localized to the SIM server trying to connect via the Global protocol settings (which typically point to a domain user in most windows enviornments).

If someone getting these errors and you are NOT running Sim please let us know.

[altonius]

We are NOT usig SIM, have the 8.1 Agents istalled and aren't receiving any of these errors, looks like the domain account may well be the problem.

[MalcO]

Worked here also, a much better solution than disabling the task.

[larden]

Thank you all for this post. I also have this issue

I couple of questions. Can I just us kill command to kill the defunct processes? What is the correct syntax, I don't want to reboot right now if I can avoid it.

What user should be in WBEM, root or just a regular user id?

[jiths]

If you are not using CIM services you can disable the same through VI Client .VI client&gt;Configuration&gt;software&gt;Advanced Settings&gt;Misc you will get an option to diable cim. Please try this and see whether it makes any difference.

[awinkel]

I had the same problem after installing Update 2 at ESX 3.5 and HP SIM 8.1

After creating local accounts (seems that they must have root access ) it seems that the processes are keeping away... I keep my fingers crossed.

[larden]

How do you get rid of the defunct process? service pegasus restart?

Also changing WBEM user account didn't fix it for me, when the task ran this AM I received more defunct processes.

Anyone get an answer from HP or VMWare?

[awinkel]

This were the steps I've taken:

- Make a local account at the ESX servers. Poorly it must be a root account but shell access is not required.

- From the Systems Insight Manager connect to the ESX server and give the credentials you've made at the ESX server.

If you use certificates do the following:

- Go to the System Management Homepage of the ESX server and click at "Settings" --> "Security" --> "Trust Mode" and choose what you want to use.

After I made the changes I put he server into maintenance mode and reboot it.

After that the processes are running fine and there are nog processes anymore.

[EPL]

Checking on my servers this morning revealed that I'm still getting these defunt processes. In the messages log, I also see that the domain username tried to authenticate so it seems that SIM was trying to use the domain user account again for some reason.

I'd be interested to know if anyone has heard anything from Vmware or HP.

[awinkel]

Why should they give a reaction at a configuration fault??? It's clear that using a domain user account can't be used against an ESX server...

This was even so before update2 when the fault wasn't logged.

Or do I mis something?

[EPL]

Pre update2 ESX did not generate hundreds and thousands of processes. There was a post earlier that said if left unattended, it can cause problems with your ESX server not being able to launch processes.

So even though its not VMWare's fault for the misconfiguration, it seems as though this Update2 is not handling the error properly and not cleaning up the failed process.

[larden]

It sounded as though a few people were going to open up cases on this issue. Seems a waste of time for us all to do it, but if we must.... Also I am not convinced that changing the WBEM resolves it, I did that and still had defunct processes. I have disabled monitoring until a 100% solution is found.

VMware Rocks!