flatpak-spawn prevents systemd from shutting down the system - Githubissues

flatpak / flatpak-xdg-utils

Simple portal-based commandline tools for use inside flatpak sandboxes

GNU Lesser General Public License v2.1

34 stars 14 forks source link

flatpak-spawn prevents systemd from shutting down the system #12

Closed refi64 closed 5 years ago

refi64 commented 6 years ago

Reproduced with Flatpak 0.99.3 on Fedora Silverblue 28.

TL;DR: Run this, then try shutting down your system:

flatpak run --command='flatpak-spawn' org.gnome.Photos sleep 30

(Any app works; I just randomly picked Photos here.)

systemd will hang for 2 minutes saying it's stuck waiting for a stop job.

Another, less drastic way to see the same issue would be to run the above, then Ctrl-C. sleep will still be running.
Any app works; I just randomly picked Photos.
Any other command passed to flatpak-spawn can reproduce the issue.
If you watch the system monitor, you'll see that every time sleep runs, another flatpak-spawn and bwrap process will appear and stay around...even after the sleep command finishes.

matthiasclasen commented 5 years ago

I don't see that happening here. all the bwrap processes that are involved in setting up the spawned sandbox are gone when the command exits, With 1.1.1

refi64 commented 5 years ago

Okay, revised command:

flatpak run --talk-name=org.freedesktop.Flatpak --command=flatpak-spawn org.freedesktop.Platform//18.08 --host sleep 30

This should be reliably reproducible.

matthiasclasen commented 5 years ago

ok, several minor issues become apparent here:

Ctrl-C kills flatpak commandline, but not the running sandbox
sleep existing does not stop flatpak-spawn
flatpak ps and flatpak kill don't deal well with app-less sandboxes
the flatpak instance api does not handle app-less sandboxes

refi64 commented 5 years ago

FWIW this is also reproducible with an actual app instead of just the plain runtime.

matthiasclasen commented 5 years ago

The part about app-less sandboxes is tangential here. And my analysis of the actual problem is still unclear.

It does seem that there is a problem with signal forwarding at least. flatpak-spawn says that it is forwarding the signal, but I never see it appear in the session helper.

Removing --host is also insightful. It turns out that you can't actually call into portals from app-less sandboxes:

Failed to call flatpak portal: GDBus.Error:org.freedesktop.DBus.Error.Failed: Authorization error: Key file does not have group “Application”

matthiasclasen commented 5 years ago

Some more playing around:

Using kill -INT to sent SIGINT just to the flatpak-spawn process does work as expected - the signal gets forwarded, the sleep process dies, and that in turn gets relayed to flatpak-spawn, causing it to exit.

Ctrl-C does not work correctly - the flatpak-spawn process is trying to forward the signal, but it gets a 'connection closed' error - my guess is that Ctrl-C kills the process group and takes down the dbus proxy first.

Maybe flatpak-spawn should die when it loses its bus connection.

matthiasclasen commented 5 years ago

I think with the just merged changes, things should work mostly as expected. You'll have to wait for 1.2 to use --watch-bus