-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AppImage orphan survives main process exit #92
Comments
Thanks @mehmetakbulut. Most likely so far never ever thought about running an AppImage in a non-interactive environment. But your use case (running an AppImage using @TheAssassin I believe this needs some debugger wizardry. |
We have this problem a lot, mostly it becomes a problem when an appimage is restarted over and over with a failing systemd unit. At some point you run into the One fix is to enable auto-unmount in squashfuse, like in https://github.com/lalten/appimage-runtime-rs/blob/03911dd353085bfd15e57e5a0cd1211f633ed656/appimage-mount/src/mount.rs#L24-L25 Squashfuse's |
The reason this happens is basically #90 (which appimage-runtime-rs also does differently, in https://github.com/lalten/appimage-runtime-rs/blob/03911dd353085bfd15e57e5a0cd1211f633ed656/src/bin/runtime.rs#L117) |
@lalten we're looking into rewriting the runtime in Rust anyway, but neither of us is fluent enough (yet, working on that). In the meantime, do you think you could contribute a similar fix to this codebase? |
Thank you guys for the quick response! I can patch runtime with timeout flags on my end as a workaround. I think that should allow mount & forked process to remain as long as main process exists? (since it is loaded from the mount?) @lalten Do you have insight into why the behavior is different with
vs
I thought maybe it has to do with the foreground flag but I don't quite follow how it would do this in the source. |
Looks like my PR is solving this now. Thanks everyone! |
@mehmetakbulut can you confirm that it works now using Thanks for testing! |
Thanks @probonopd, works well on my end! |
I think once AppImage/AppImageKit#93 is merged, we can close this issue. I suspect it should resolve #99 as well. Unrelated to this issue but just for my understanding: is there a suggested way to consume type2-runtime in bazel? We have been using @lalten's fork since it had a more recent tagged/release build but even that is ~2 years behind. It has some additional commits so I am wondering if those are important to keep in a bazel workflow with rules_appimage? The CI builds from AppImage/AppImageKit#93 worked fine to build and run an appimage via bazel. We haven't been using |
The additional commits in that repo don't really matter, it was me trying to automatically generate a release for every single commit 🙈 |
ah, I take it back, there are indeed some useful commits related to fuse3 handling: main...lalten:type2-runtime:main |
I thought it was this repo, but regarding the unstable release hashes I'm referring to probonopd/static-tools#41 |
Thanks lalten! Yeah, there are no manual or automatic tagged/releases in this repo that allow a stable reference from outside. If you are able to update your repo after AppImage/AppImageKit#93 is merged, I think that would be very helpful. 😃 Regardless, I can build/mirror on my end so it is not a major issue. |
I had to research what Bazel is but ideally it should stay away from using |
I am seeing an orphaned process get left behind under some conditions after main process exits. This orphaned process seems to stay around forever in sleep state until reboot. I originally noticed this when appimage was run by a process running as a systemd service similar to #99 so I have put together the following example without systemd.
Running as root to demonstrate that it should not be a permissions issue.
Using following as entrypoint from appimage wrapper:
Running with strace to trace processes. We can see that main process forks pid 30812 (which I believe is this fork call) which then forks again with pid 30813. Main process then eventually execs our "Hello world!" script which exits properly. However we can see that a detached process is left behind which is pid 30813.
30813 appears to be in sleep state while reading fuse device.
We can further confirm this. It is currently trying to read fd 5 which is
/dev/fuse
.However if we run in an interactive environment (like most people would be doing by launching an application on their desktop or shell) using
bash -i
, then everything works properly with no detached processes left behind.In this case, detached process would have been pid 31936 (2nd forked process after appimage is exec'd) however it sends itself a SIGTERM after main process exits.
I have walked through appimage runtime, squashfuse and libfuse sources without much progress. I think I am missing some insight. Maybe this is intended behavior or some user error on my end.
The text was updated successfully, but these errors were encountered: