this should work but my first problem still remains I am on

Question

this should work but my first problem still remains I am on another VM and I see that a orphan osqueryd started by service is holding db LOCK file and since my extension could not connect to osquery it try to restart osquery using `net` but the new osqueryd cannot get the LOCK since it is held by the zombie osqueryd if I kill the zombie process I see that the LOCK file still exist this is the problem I am trying to solve

Mike Myers · Answer

When you say orphan osqueryd is it still running Why is it a zombie

Arvind D · Answer

so I saw in the `process explorer` that it does not have a parent

Arvind D · Answer

our install and uninstall for osquery is customized and I suspect that the install is not cleaning up the old install correctly so a zombie osquery is still hanging to the resources osquery em and LOCK for db but killing the zombie process does not release the resources

OpenPlgx · Answer

Your extension is starting osquery

OpenPlgx · Answer

What do you mean zombie osquery In windows and most OSes I guess when a user mode process dies all the open handles are released what makes you think your zombie osquery is keeping a handle open

Arvind D · Answer

osquery is a system process and it is run by service for the first time

Arvind D · Answer

I see that the orphan zombie process is holding osquery em and LOCK file I can see it in process explorer

Arvind D · Answer

the extension starts it only if it is not able to connect to osqueryd

Arvind D · Answer

this is to avoid the state where osquery is stuck and there is not communication between the extension and osquery

OpenPlgx · Answer

I see we do something similar but thru an outside monitoring service because we auto load our extension

Arvind D · Answer

ohh I see can this scenario be possible in weaker VMs where windows does not release resources fast and as a result if your installer does not wait for the things to clean up the osquery can end up in this state