-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Agent] Elastic Agent Unenroll Action Leaves Dormant Service and Process Running #24568
Comments
Pinging @elastic/agent (Team:Agent) |
This look like something we need to investigate from our users @mostlyjason, as engineer we considered we shouldn't mess around with services after the unenrollment was done and we would expect user to manually uninstall the elastic agent on the machine. Can we clarify our users expectation here? |
Good point! I don't think its a bug because it is performing the requested action, which is to unenroll the agent. However, I agree its a little confusing because what is the point of running without an agent policy? What about disabling the services when the agent does not have an agent policy? That should stop the processes without uninstalling them. I think we expect the user to uninstall the agent after unenrolling it. Perhaps we can optimize this in the future to happen in one step instead of two. That said, I think we should prioritize getting agents enrolled, and come back to optimizing the unenrolling/disabling behavior later. I'd say we should track this item on the backlog for now. |
@mostlyjason thanks for input, +1 to add to the backlog. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
++ |
@gabriellandau the point/idea was that if we exit agent which is managed by service manager (e.g systemd) it will get restarted and then we end up in a restart loop because without policy we dont need to run. |
Thanks for the response @michalpristas
I am suggesting that we uninstall Agent, not exit it. Rename |
This sounds very familiar to the issue that I had in |
Running 8.4.2 now and the issue still persists ps aux | grep 'Z' |
All of my linux hosts where my Agents are running present the same behavior |
Bump @ph @michalpristas @cmacknz @nimarezainia @bjmcnic This over-two-year-old confusing behavior has now resulted in at least one user with zombie Endpoints and Agents installed. The user still has access to Kibana, but has no way to uninstall these Agents and Endpoints. This can happen, for example, when IR / MDR contracts end.
We already do this for local uninstalls (e.g. We're willing to add a service when users install Agent locally. Why are we requiring them to shell into each machine to uninstall agent? |
I don't think there's a good reason for this, considering that we already support the uninstall command that does remove the agent correctly on every supported platform. I'll leave it to @nimarezainia to prioritize this from the product side, although possibly improvements here could be tied in with the ongoing tamper protection work since we are already changing the uninstallation flow there. CC @roxana-gheorghe |
Support for full removal will be based on the installation type. We should really only support full uninstall doing unenrollment if the elastic-agent is installed using the |
still happening on the latest 8.11.1 |
The zombie processes after a restart are now tracked in elastic/elastic-agent#2190 (comment) |
@cmacknz perhaps the title of this issue was a misnomer. I just renamed it. |
Ah yes I just pattern matched to the word zombie. Thanks that clarifies things, different issue and yes still a problem. |
Describe the bug
I installed a 7.12.0 BC4 Agent onto Windows 10 using the provided command line. It installed itself and the Endpoint.
When I unenrolled the Agent via Security App, it uninstalled Endpoint but left the Agent process running and the service registered:
Process, service, and files are still present:
This is documented behavior, but I believe it goes against user expectations. Why would a user want a zombie Agent left running on their endpoint after explicitly unenrolling it?
If we change this to behavior, we may want to update the Security App verbiage to "Uninstall Endpoint".
Desktop (please complete the following information):
And thank you to @gabriellandau for logging this initially - I'll close the private issue in the security team repo in favor of this (cannot transfer from private to public repo).
The text was updated successfully, but these errors were encountered: