Open mehmetakbulut opened 3 days ago
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 systemd
) is a valid one, and maybe there are others.
@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 mount_max
limitation of Fuse (default is 1000).
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 appimage-runtime-rs isn't quite ready for primetime though.
Squashfuse's -o timeout=N
means "idle N seconds for automatic unmount"
Fuse's auto_unmount
"enables automatic release of the mountpoint if filesystem terminates for any reason"
The reason this happens is basically https://github.com/AppImage/type2-runtime/issues/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 bash -i
?
# without bash -i
[pid 30815] --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=30813, si_uid=0} ---
[pid 30815] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=30813, si_uid=0} --- # detached process sends sigterm to some other child process
[pid 30815] +++ exited with 0 +++
^Cstrace: Process 30813 detached
vs
# with bash -i
[pid 31937] --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=31936, si_uid=0} ---
[pid 31936] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=31936, si_uid=0} --- # detached process sends sigterm to itself
[pid 31937] +++ exited with 0 +++
+++ exited with 0 +++
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!
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 AppImage/AppImageKit#1362 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.