• CameronDev
    link
    fedilink
    arrow-up
    83
    arrow-down
    1
    ·
    edit-2
    6 months ago

    Zombie processes are already dead. They aren’t executing, the kernel is just keeping a reference to them so their parent process can check their return code (waitpid).

    All processes becomes zombies briefly after they exit, just usually their parents wait on them correctly. If their parents exit without waiting on the child, then the child gets reparented to init, which will wait on it. If the parent stays alive, but doesn’t wait on the child, then it will remain zombied until the parent exits and triggers the reparenting.

    Its not really Linux’s fault if processes don’t clean up their children correctly, and I’m 99% sure you can zombie a child on redox given its a POSIX OS.

    Edit: https://gist.github.com/cameroncros/8ae3def101efc08be2cd69846d9dcc81 - Rust program to generate orphans.

    • senkora@lemmy.zip
      link
      fedilink
      arrow-up
      3
      ·
      6 months ago

      I haven’t tried this, but if you just need the parent to call waitpid on the child’s pid then you should be able to do that by attaching to the process via gdb, breaking, and then manually invoking waitpid and continuing.

      • CameronDev
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        6 months ago

        I think that should do it. I’ll try later today and report back.

        Of course, this risks getting into an even worse state, because if the parent later tries to correctly wait for its child, the call will hang.

        Edit: Will clean up the orphan/defunct process.

        If the parent ever tried to wait, they would either get ECHILD if there are no children, or it would block until a child exited.

        Will likely cause follow on issues - reaping someone elses children is generally frowned upon :D.