virtme-init: Reap zombie processes by amorenoz · Pull Request #428 · arighi/virtme-ng

amorenoz · 2026-02-28T17:29:06Z

If the users create ofphaned processes, it's init's task to reap them or else they'll remain as zombies.

For example:

vng --user root
          _      _
   __   _(_)_ __| |_ _ __ ___   ___       _ __   __ _
   \ \ / / |  __| __|  _   _ \ / _ \_____|  _ \ / _  |
    \ V /| | |  | |_| | | | | |  __/_____| | | | (_| |
     \_/ |_|_|   \__|_| |_| |_|\___|     |_| |_|\__  |
                                                |___/
   kernel version: 6.19.0-virtme x86_64
   (CTRL+d to exit)

bash-5.3# (setsid sleep 1 &); sleep 2; ps aux | grep 'sleep'
root       342  0.0  0.0      0     0 ?        Zs   18:11   0:00 [sleep] <defunct>
root       345  0.0  0.0   3464  1932 ttyS0    S+   18:11   0:00 grep 'sleep'
bash-5.3#

Replace the specific waitpid (internal to Command::output()) with a simple loop that will also reap zombies if they appear.

rbmarliere · 2026-03-01T11:44:31Z

Does the same happen with the shell init? (--no-virtme-ng-init)

amorenoz · 2026-03-04T11:28:30Z

Does the same happen with the shell init? (--no-virtme-ng-init)

No, that one seems to work all right.

It seems clippy is not happy if we don't call Process::wait so maybe we need to spawn a thread that does the zombie reaping after all (I tried to avoid it precisely because it could interact with the other Process::wait).

amorenoz · 2026-03-05T15:55:31Z

Is --no-virtme-ng-init planned to stay around or is the plan to remove it eventually?

marcosps · 2026-03-05T16:08:04Z

Is --no-virtme-ng-init planned to stay around or is the plan to remove it eventually?

Well, I find it useful. In places where I just clone virtme-ng, I can start a VM without having cargo/rust around. For most cases, maybe people will use the packaged version, but at least for me, the recent fixes are important for my workloads.

matttbe · 2026-03-05T16:14:17Z

The Bash version is also easier to hack to quickly try things, and it doesn't have some optimisations done in the Rust version which could cause some issues.

Also, please note that some packages still don't contain virtme-ng-init, e.g. on Debian and cie.

If the users create ofphaned processes, it's init's task to reap them or else they'll remain as zombies. For example: vng --user root _ _ __ _(_)_ __| |_ _ __ ___ ___ _ __ __ _ \ \ / / | __| __| _ _ \ / _ \_____| _ \ / _ | \ V /| | | | |_| | | | | | __/_____| | | | (_| | \_/ |_|_| \__|_| |_| |_|\___| |_| |_|\__ | |___/ kernel version: 6.19.0-virtme x86_64 (CTRL+d to exit) bash-5.3# (setsid sleep 1 &); sleep 2; ps aux | grep 'sleep' root 342 0.0 0.0 0 0 ? Zs 18:11 0:00 [sleep] <defunct> root 345 0.0 0.0 3464 1932 ttyS0 S+ 18:11 0:00 grep 'sleep' bash-5.3# Replace the specific waitpid (internal to `Command::output()`) with a simple loop that will also reap zombies if they appear. Signed-off-by: Adrian Moreno <amorenoz@redhat.com>

amorenoz · 2026-03-06T08:21:38Z

Since there is a workaround, this is not a big issue for me anymore. Feel free to close the PR. If you would like this issue to be solved in the rust init in any other way, let me know and I'll give it a try.

matttbe · 2026-03-06T11:35:06Z

I think it is fine to ignore the clippy warning, but I'm not a rust expert. @arighi WDYT?

arighi · 2026-03-06T23:56:52Z

Is --no-virtme-ng-init planned to stay around or is the plan to remove it eventually?

The bash init is definitely going to stay. We can't cross-compile virtme-ng-init for all the architectures and the bash init allows to easily support them (--arch).

arighi · 2026-03-07T00:00:34Z

If the users create ofphaned processes, it's init's task to reap them or else they'll remain as zombies.

Nit: "ofphaned" -> "orphaned"

arighi · 2026-03-07T00:02:21Z

virtme_ng_init/src/main.rs


+fn wait_for_child(child: i32) {
+    loop {
+        match wait() {


wait() can fail with EINTR when the process receives a signal. Right now any error leads to a log + return, so the direct child is never reaped and can stay a zombie. Maybe add:

Err(Errno::EINTR) => continue,

arighi · 2026-03-07T00:05:26Z

virtme_ng_init/src/main.rs

-            .output()
+            .spawn()
            .expect("Failed to start shell session");
+        wait_for_child(child.id() as i32);


Maybe we should apply the same spawn/wait pattern to run_user_script() as well?

arighi · 2026-03-07T00:08:50Z

I think it is fine to ignore the clippy warning, but I'm not a rust expert. @arighi WDYT?

I think it's correct to ignore: the warning is because we spawned a child without waiting on it, but we do wait (via a custom wait() loop), so it's just lint that doesn't understand this pattern.

matttbe

(adapting the status after Andrea's review, plus there are some conflicts to solve if you don't mind rebasing)

arighi · 2026-03-10T06:08:11Z

BTW, I'm not able to reproduce this problem, I don't see any zombie tasks. Did it go away with some of the recent changes?

matttbe · 2026-03-10T10:37:16Z

BTW, I'm not able to reproduce this problem, I don't see any zombie tasks. Did it go away with some of the recent changes?

I can still reproduce it on my side:

$ ./vng --user root -r
# (setsid sleep 1 &); sleep 2; ps aux | grep "[s]leep"
root      1102  0.0  0.0      0     0 ?        Zs   11:31   0:00 [sleep] <defunct>

(also without --user root)

As @amorenoz said before, this issue is only with vng-init, not with the bash init script.

How did you try?

arighi · 2026-03-10T16:07:22Z

$ ./vng --user root -r
# (setsid sleep 1 &); sleep 2; ps aux | grep "[s]leep"
root      1102  0.0  0.0      0     0 ?        Zs   11:31   0:00 [sleep] <defunct>

@matttbe Ah yes, with this I can reproduce it. Ok, then we should fix this and once we land this one we can cut a new version, wdyt?

matttbe · 2026-03-10T16:11:57Z

Ok, then we should fix this and once we land this one we can cut a new version, wdyt?

Good idea to cut a new version!

Do you mean you are planning to apply the suggestions you sent here?

rbmarliere · 2026-03-10T16:17:42Z

@arighi #445 might be worth including in the new version, thx!

arighi · 2026-03-10T16:55:31Z

Ok, then we should fix this and once we land this one we can cut a new version, wdyt?

Good idea to cut a new version!

Do you mean you are planning to apply the suggestions you sent here?

Yeah we need to resolve the conflicts and include my comments, if @amorenoz doesn't have time maybe I can add these changes on top of this commit.

amorenoz force-pushed the fix-zombies branch from 5e685d2 to 844505e Compare March 6, 2026 08:13

arighi reviewed Mar 7, 2026

View reviewed changes

matttbe requested changes Mar 7, 2026

View reviewed changes

Conversation

amorenoz commented Feb 28, 2026 • edited by matttbe Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rbmarliere commented Mar 1, 2026

Uh oh!

amorenoz commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amorenoz commented Mar 5, 2026

Uh oh!

marcosps commented Mar 5, 2026

Uh oh!

matttbe commented Mar 5, 2026

Uh oh!

amorenoz commented Mar 6, 2026

Uh oh!

matttbe commented Mar 6, 2026

Uh oh!

arighi commented Mar 6, 2026

Uh oh!

arighi commented Mar 7, 2026

Uh oh!

arighi Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

arighi Mar 7, 2026

Choose a reason for hiding this comment

Uh oh!

arighi commented Mar 7, 2026

Uh oh!

matttbe left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arighi commented Mar 10, 2026

Uh oh!

matttbe commented Mar 10, 2026

Uh oh!

arighi commented Mar 10, 2026

Uh oh!

matttbe commented Mar 10, 2026

Uh oh!

rbmarliere commented Mar 10, 2026

Uh oh!

arighi commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

amorenoz commented Feb 28, 2026 •

edited by matttbe

Loading

amorenoz commented Mar 4, 2026 •

edited

Loading

matttbe left a comment •

edited

Loading