Confined daemon and GUI, DBus communication

rinigus

I am in the process of rewriting OSM Scout Server into two separate applications:

daemon performing actual work
GUI allowing to adjust daemon settings, instruct on map datasets management

Such separation would allow to keep daemon running in the background all the time with minimal memory and CPU impact. When not in use, the daemon will wait for connection with it to fork into full-blown mode supporting all required operations (serving map tiles, search and routing). After idle period, it will transfer into original waiting mode with reduced impact.

This transition will allow to support Linux variants that do not ship with systemd or other init system supporting socket activation. Examples include pmOS or Flatpak packaged OSM Scout Server.

However, it raises few questions regarding UT support. Maybe someone can help me here to find replies and/or propose solutions to the issues arising from such partitioning:

can I have multiple programs in the same click package? In this case, osmscout-server and osmscout-server-gui
can I run multiple programs from the same click package? one GUI and one daemon, in my case
can these programs communicate with each other via session dbus?
does UT support dbus activation for confined apps? As if one of the click installed program (GUI) tries to access the other program in the same click (daemon)
can user craft together init script and install it for running a service via confined daemon? Will probably come as suggested mod for users that they will have to do manually on their devices. Such as copying init script to start daemon on boot
as far as I remember, it is impossible to communicate via dbus for confined applications installed from separate click packages. is it (still) true?

jonius

@rinigus I'll summarize the answers from the telegram channel so far:

you can do a confined dbus client/server in same click, having your own private bus with dbus using a unix socket under $XDG_CACHE_HOME for example
You can have multiple apps within one click, https://open-store.io/app/neverball.abmyii is an example
there is currently no solution for background services in a confined app

jonius

Maybe neverball is not even the best example, as that are two apps within one click, but we probably need just one app with with a normal app and a daemon which can run as long as the app has focus or continuously if the user disabled app suspension for it (as we currently suggest for OSM Scout Server).

rinigus

Not sure how this app suspension will work for daemon. I wonder if that will be suspended at all if we have two processes running from the same click package.

Re private dbus: OK, so we have to start that as well in our case.

So, if we have separation, we need some kind of launch script that will start:

DBus
daemon
GUI

After starting DBus and daemon, that launch script can probably exec into GUI.

On closing GUI, we will probably have to shutdown the daemon as well, unless user will ask to keep it.

From this discussion, it looks like while separation into daemon + GUI makes sense in classical Linux, it does cause some pain on UT. (And I am ignoring official store requirements on SFOS.)

In principle, we can also keep separate UT branch with the current type of implementation. As most of the changes are expected in the backend libs and not the server itself, it would probably work for some time. And later revisit situation.

Alternative would be to try to move osmscout-server daemon into DEB. But that sounds not trivial in UT, as far as I can see.

dobey

@rinigus said in Confined daemon and GUI, DBus communication:

can I have multiple programs in the same click package? In this case, osmscout-server and osmscout-server-gui

Programs (binaries) or applications (which are started from the app drawer)? In short, the answer is yes, you can have as many binaries in your click as needed. Generally, multiple applications is discouraged though.

can I run multiple programs from the same click package? one GUI and one daemon, in my case

Yes, your application can spawn a child process, and it will be under the same confinement profile as your app.

can these programs communicate with each other via session dbus?

No, the session and system bus addresses are generally confined. However, dbus can be used on a private bus, using a domain socket file inside your package's cache directory, for example.

does UT support dbus activation for confined apps? As if one of the click installed program (GUI) tries to access the other program in the same click (daemon)

It does not. You would need to manage creating the private bus and starting the background process yourself.

can user craft together init script and install it for running a service via confined daemon? Will probably come as suggested mod for users that they will have to do manually on their devices. Such as copying init script to start daemon on boot

There is no general support for having click packages provide background services, or having other clicks have the ability to talk to services provided by a click, currently. So no, there is no way to have confined background services that run outside of the process stack of the application itself.

as far as I remember, it is impossible to communicate via dbus for confined applications installed from separate click packages. is it (still) true?

Yes, separate confined click apps cannot talk to each other via dbus.

dobey

@rinigus said in Confined daemon and GUI, DBus communication:

Not sure how this app suspension will work for daemon. I wonder if that will be suspended at all if we have two processes running from the same click package.

Yes, all child processes of the app will also be paused.

rinigus

@dobey, thank you very much for replies!

Plan is to have only one executable that is exported into app drawer, GUI part. Or taking into account your replies, some master script starting all components.

Sounds like it is possible to have such separation on UT as well. However, at this time, it will just add some complexity without any benefit.

What is not clear what will happen on the case of GUI app shutdown. So, assuming I have a script along lines

#!/bin/sh
start dbus &
start daemon &
exec gui

and gui gets closed by the user. Will all processes started in that confined env be killed? If yes, which signal(s) will be used?