Can not get correct pid in WSL2

user_17435393 0
Viewed 430

I am learning Linux programing.
When I trying to write a simple module to get family of a process, I find I can not get current pid of a process and its parent process. How to fix it?
Here is a part of my code.

static pid_t pid = 1;
module_param(pid, int, 0644);

static int hello_init(void) {
    struct task_struct *p;
    struct list_head *pp;
    struct task_struct *psibling;
    struct pid *kpid;

    kpid = find_get_pid(pid);
    p = pid_task(kpid, PIDTYPE_PID);
    printk("me: %d %s\n", pid, p->comm);
    if (p->parent == NULL) {
        printk("No Parent\n");
    }
    else {
        printk("Parent: %d %s\n", p->parent->pid, p->parent->comm);
    }
    list_for_each(pp, &p->parent->children) {
        psibling = list_entry(pp, struct task_struct, sibling);
        printk("sibling %d %s \n", psibling->pid, psibling->comm);
    }
    list_for_each(pp, &p->children) {
        psibling = list_entry(pp, struct task_struct, sibling);
        printk("children %d %s \n", psibling->pid, psibling->comm);
    }
    return 0;
}

result:

sudo insmod module.ko pid=1
dmesg
[ 6396.170631] me: 237 systemd
[ 6396.170633] Parent: 235 unshare
[ 6396.170633] sibling 237 systemd
[ 6396.170633] children 286 systemd-journal
[ 6396.170634] children 306 systemd-udevd
[ 6396.170635] children 314 systemd-network
[ 6396.170635] children 501 snapfuse
[ 6396.170636] children 508 dbus-daemon
[ 6396.170636] children 509 NetworkManager
[ 6396.170637] children 632 systemd-logind
[ 6396.170637] children 639 systemd
[ 6396.170638] children 665 rtkit-daemon
[ 6396.170638] children 671 polkitd
[ 6396.170638] children 711 udisksd
[ 6396.170639] children 761 upowerd
wsl-2 windows-subsystem-for-linux linux
1 Answers

I'm not a Linux systems development expert, but I'll take a stab at helping based on what I see you trying.

First, you don't mention it in your question, but you are clearly running some sort of Systemd enablement. As you know, Systemd isn't normally supported on WSL. At a high level, the scripts to enable Systemd on WSL all have two essential functions:

  • Create a new PID namespace where Systemd is running as PID1. At the most basic level, this can be done via:

    sudo -b unshare --pid --fork --mount-proc /lib/systemd/systemd --system-unit=basic.target

    We can see the unshare in the list of processes returned, so that's getting called, at least.

  • Wait for Systemd to fully start, then enter the namespace that was created above. This is typically something like:

    sudo -E nsenter --all -t $(pgrep -xo systemd) $SHELL

    The actual scripts are typically a bit more complicated in order to handle multiple shells, distributions, etc. They also attempt to preserve more of the WSL environment inside the namespace in order to enable the Interop features such as running Windows .exes. But the core concept is always the same.

So, taking a guess here (again, as a non-systems-dev guy), it seems that:

  • kpid=find_get_pid(1) is returning the systemd process inside the namespace

  • pid_task(kpid, PIDTYPE_PID) is returning the "true" process information from the root namespace.

    It seems to me that code must be running outside the namespace, since you see the unshare as part of it. From within the namespace, the unshare doesn't exist. You can verify this (inside the namespace) with ps -ef | grep unshare.

There are at least two possible solutions:

  • If it's not an issue (and from the comments, it wasn't), then just run your code from the root pid namespace. I'm assuming that your Systemd script is running via your shell startup files, so you should be able to get back to the root namespace by starting up with something like wsl ~ -e bash --noprofile --norc. This will start the shell without any of the startup scripts.

    Of course, other techniques for disabling the Systemd script are probably documented by whatever script you are using.

  • If you do want your code to work properly from within a PID namespace, then you'll probably need to find the namespace (I'd start with the source of lsns as an example). Then find the task struct within that namespace (probably find_task_by_pid_ns?).

user_118109330
Related