The tracking of orphan processes is lost.

[ChrisLiCheng]

Motivation

The motivation behind this request is to be able to trace all descendant processes created after specifying proc.apid=xxx and track them starting from pid=xxx. This is essential for monitoring and managing processes efficiently, especially in scenarios where sysdig loses track of child processes once the parent process exits and the child process is inherited by the process with pid=1.

Feature

I am requesting a feature that allows sysdig to continue tracking child processes even after the parent process has exited and the child process becomes managed by the init process (pid=1). Currently, sysdig loses track of these child processes, making it challenging to monitor their behavior.

Alternatives

Considering specifying proc.name or proc.aname in the tracking conditions is one alternative to address the issue of losing track of orphan processes when the process name remains the same. However, in cases like the one demonstrated in my example, proc.name or proc.aname can also change, rendering this approach ineffective.

An additional alternative, as mentioned in my initial message, is to run the target program inside a container and track events for the entire container. This approach can help maintain visibility into child processes even when they are inherited by the init process. However, it may not be a feasible solution in all situations, and having a built-in feature within sysdig would provide a more versatile and streamlined solution.

Additional context

Below is my test program.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/prctl.h>

int main(int argc, char *argv[])
{
    if (argc == 2 && strcmp(argv[1], "child") == 0)
    {
        pid_t pid = fork(); 

        if (pid < 0)
        {
            perror("fork failed");
            exit(EXIT_FAILURE);
        }

        if (pid > 0)
        {
            printf("Parent process (PID %d) is exiting.\n", getpid());
            exit(EXIT_SUCCESS); 
        }

        printf("Child process (PID %d) started.\n", getpid());

        const char *new_name = "newproc";
        prctl(PR_SET_NAME, new_name, 0, 0, 0);

        if (argc > 1)
        {
            char *cmdline = argv[1];
            int i;
            for (i = 1; i < argc; i++)
            {
                memset(argv[i], 0, strlen(argv[i]));
                if (i < argc - 1)
                {
                    argv[i + 1] = argv[i] + strlen(argv[i]) + 1;
                }
            }
            strncpy(argv[0], cmdline, strlen(cmdline));
        }
        while (1)
        {
            sleep(5); 
            printf("Child process (PID %d) is still running...\n", getpid());
        }
    }
    else
    {
        char *newLocation = "/tmp/new_executable";
        char command[256];

        sprintf(command, "cp %s %s", argv[0], newLocation);
        system(command);

        sprintf(command, "chmod +x %s", newLocation);
        system(command);

        execl(newLocation, newLocation, "child", (char *)NULL);
    }

    return 0;
}

[Andreagit97]

ei @ChrisLiCheng thank you for reporting! The feature request makes sense! If I understood well you would like to track all descendant processes created by a specific pid. So in some way we should save who is the original father of the thread and keep this information, I'm just wondering if we cannot achieve this using the session-id, do you have an example use case associated with the feature request? Just to understand if we can cover these use cases with the session-id or if we definitely need an additional info

[ChrisLiCheng]

Hi @ChrisLiCheng,

Thank you for your response and your consideration of my feature request. To provide further clarification on my use case, I'm working in a scenario where I need to analyze unknown programs, and it's crucial for me to track not only the direct child processes of a specific PID but also all descendant processes, including orphan processes.

The reason I mentioned potential issues with using the session ID (sid) is that in my analysis, I've encountered situations where the program can modify or set a new sid, making it unreliable for my purposes. I need a more robust and reliable way to trace the ancestry of processes, regardless of any modifications they may make to their session IDs.

I hope this clarifies my requirements better. If you have any further questions or need more details, please feel free to ask. Your help in addressing this need is greatly appreciated.

[Andreagit97]

uhm, thank you for the additional context! at the moment I have no further questions, we will evaluate the feature request!

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[Andreagit97]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[Andreagit97]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[Andreagit97]

/remove-lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[Andreagit97]

/remove-lifecycle rotten

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale