this post was submitted on 07 Jul 2024
839 points (92.7% liked)

linuxmemes

21172 readers
902 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] CameronDev@programming.dev 82 points 4 months ago* (last edited 4 months ago) (1 children)

    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 3 points 4 months ago (1 children)

    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@programming.dev 8 points 4 months ago* (last edited 4 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.