Problems with long running child processes inside the sandbox

[hadess]

FeedReader is an RSS reader, with a UI, and a separate daemon that takes care of downloading images, files, etc.

When FeedReader is started, it starts its own little daemon inside the sandbox. But when closing the main program, the daemon is not stopped. We should have a way to tell it to close first nicely, then yank the sandbox underneath it.

In the longer term, it might be useful to allow a smaller part of the application to stay running, allowing for limited background networking access for this purpose.

CC: @jangernert

[xarbit]

@hadess
that is actually intended.. You then get notifications when new Feeds arrive even when the app is shutdown.
If you want the deamon to stop, then we need to address that with FeedReader..
For what its worth, you could set the sync parameters in the application settings to a higher value.

[hadess]

that is actually intended.. You then get notifications when new Feeds arrive even when the app is shutdown.
If you want the deamon to stop, then we need to address that with FeedReader..
For what its worth, you could set the sync parameters in the application settings to a higher value.

That's fine, except that it's not possible to reopen the app in the same container using gnome-shell. I guess it's possible to get it to reopen through the daemon's notifications, but no other way. Nothing holds the app's bus name, so we just reopen a new container, etc.

So, we need a way to fix this.

[jangernert]

Wouldn't killing the process defeat the whole reason to have a daemon in the first place?

[TingPing]

Ideally the daemon re-uses the same dbus name so launching it again just activates the same instance.

[alexlarsson]

Yeah, I'm not sure killing the daemon is the right solution here. That just destroys the background notification feature. Everything would work fine if the new instance would launch in the same container, which could be handled by the daemon owning the app name and handing over control to the app when it starts it.

[hadess]

The D-Bus name isn't owned by anyone, how would the launcher (outside the sandbox) know to launch the new UI in the same sandbox rather than a new one?

I don't think this can be easily implemented with 2 separate processes when the one that owns the name goes away. Nothing wrong with the owning process keeping running, as long as it drops its caches, etc.

[alexlarsson]

BTW. Is there a problem with the daemon and the frontend running in different sandboxes?

[hadess]

BTW. Is there a problem with the daemon and the frontend running in different sandboxes?

It would make app lifecycle harder to handle.

[alexlarsson]

@hadess Actually, its probably not that hard to make this work in feedreader itself. DBus has this queue for name ownership, so the daemon could just queue up for the name and then inherit it when the main process goes away. Then it could listen for re-activation (assuming the desktop file uses dbus activation) and spawn a new instance on activation.

[jangernert]

@alexlarsson okay, lets assume I figure out all the DBus-stuff you just talked about. How would I spawn the feedreader process? Would a simple GLib.Process.spawn from the daemon spawn the feedreader process in the same container? (even if there was a traditional package or locally compiled version of FeedReader on the system?)