Discovery: when are records for running processes a) created; b) updated; c) not changed; d) deleted?

[haldroid]

We are running nightly scans on our Linux servers. The table Running Processes [cmdb_running_process] is of interest for config audit and diagnostics. From one scan to the next, suppose a process is restarted and returns with a new PID - is a new running process record created and the old one deleted? Is the original record updated? Same questions if a parameter is changed ... If there is no change to PID & parameters on a scan, is the running process record updated? What determines when/if a running process record is deleted? I haven't found anything in the docs on this. Flowchart or pseudocode would help!

We have similar questions for discovered applications, but I'm going to put them under a separate topic.

[haldroid]

Thanks, Doug! I'm not going to mark this as answered, because now I'm curious to know the results of the bug fix.

On what fields does discovery coalesce records for running processes? Command? Parameters? Name? PID? Ports? Any or all of the above? From your reply, I'm guessing it's the full command and not PID or ports, or at least it is supposed to be that.

We run multiple instances of some processes on a single server, with a command parameter identifying each instance. I'd like the ability to coalesce based on command only; if the process is restarted from one scan to the next and the PID changes, it would be nice to keep the record for that process and just update the PID attribute.

[doug_schulze]

Hal, have PRB571273 opened to address this and let the dev team know your feedback!

[manishm]

Hi Doug / Hal,

Was this issue resolved? I am seeing the same behavior as reported in this thread. We have new Oracle instance CI records being created because a new running process record is being created. The interesting part is that we cannot get to the old running process record, in List v3, I see that there is a sys_id for the running process which when clicked points to a "Record Not found". In list v2, the running process shows empty in the list view.

Another interesting part is that the Oracle instance CI was not discovered in a long time (Most recent discovery dates back to a year) and suddenly it is discoverable again. We recently went from Geneva to Istanbul and am not sure if the upgrade has something to do with it.

Can you please suggest.

Thanks,

Manish

[cyked]

Hi Manish,

Running processes are "pruned" regularly.   As servers are discovered, discovery keeps track of the running processes on the server as either absent or not absent (its a T/F flag).   When a server is discovered and a known associated running process is NOT found that running process is marked as absent = true.   If the server continues to be discovered for the next 30 days successfully and that process is NOT restarted and discovered, it is deleted > the running process is removed from the table.   This is why you get "record not found"a and why the running process field is empty in the list view.  

There is a sys property which controls this, though I'm not finding it right now.   I changed ours to 60 days.   So your oracle instance is the same behavior.   Its a difficult balancing game.

Example: Given an organization where you track Oracle DB instances.   If you are discovering an oracle instance on a unix_server1 that is version 10g and you upgrade it to 11g, the parameters and command string of the running process are likely to change.   Is that a "different/new" CI?   To some companies, the answer may be yes, others may be no. But, if you do not have a process handler in place to address key_parameters field you WILL get a new CI created from the new running process record.

[Kody]

fyi)

You can see the functionality as Table Cleaner and sys_auto_flush_list.do