On Mon, 26 Nov 2018 at 20:04, Owen Taylor <otaylor(a)redhat.com> wrote:
On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
> 1) if dbus service crashes/is not availaible temporary IMO it wold be
> good to prepare whole desktop apps code to not crash but handle dbus
> disconnection and maybe display centered message that it is not
> possible to connect to dbus. Crashing everything looks really *bad*.
The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.
Cleaning the session is perfect example of what can be done with using
Solaris contracts which is kind of grouping attribute for some group
of processes which needs to be treated as the group. When session
needs to be closed all processes which are part of the contract needs
to be killed by contract id (which works like task id or pid).
Lack of contacts is IMO another cause current systemd complexity
(Solaris SMF for example kills all service processes by not looking
for all PIDs but simple by killing all processes with the same ctid).
Is it any other propose of the dbus communication? (my question is
more about original initial design than what is now)
I'm asking because I do not fully understand of the cause why dbus has
been designed and to solve current design issue original cause of
erecting/designing such communication needs to be well understood.
Plus, when the connection to the bus is lost, all assumptions that
the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.
Looks like again contracts could solve such scenarios with sending
normal signal to PID 1 (like HUP) with masking to be received by all
processes with the same ctid. No new communication or protocols ..
just minute modifications of well known signal handlers.
https://docs.oracle.com/cd/E18752_01/html/816-5174/contract-4.html#REFMAN...
This idea already is used on live systems from more than decade.
kloczek