Skip to content

Conversation

frazew
Copy link

@frazew frazew commented Jun 11, 2025

-recheck already allows process_exporter to put processes which might change name after they start in the right group. However this only works if the initial process name is not matched. In case a matcher catches it early, the process is left in its old group after its name changes.

This can be observed with a generic configuration like this:

process_names:
  - name: "{{.Comm}}"
    cmdline:
      - '.+'

If a process called process1 with PID 1234 starts and later execs and changes its name to process2, then 1234 remains in the process1 group even though it should now be in a new process2 group.

This PR removes the assumption that GetStatic is static, and instead retrieves and updates it at each scrape. I believe this should not have any noticeable performance hit?

  • if recheck (or recheck-with-time-limit) is enabled, the process is allowed to change groups after it has started
  • if the new process name is no longer matched by the namer, the process is ignored
    I'm not sure about that last behavior: is it Update the right place to do it? Could it break tracking of child processes?

@frazew frazew force-pushed the recheck-support-name-change-if-tracked branch from 07d2991 to 2ddfc56 Compare June 11, 2025 15:25
-recheck already allows process_exporter to put processes which might
change name after they start in the right group. However this only works
if the initial process name is not matched. In case a matcher catches it
early, the process is left in its old group after its name changes.
@frazew frazew force-pushed the recheck-support-name-change-if-tracked branch from 2ddfc56 to a6cb1ce Compare June 11, 2025 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant