Tracking Application Lifetime [again]
Milosz Derezynski
internalerror at gmail.com
Fri Aug 8 12:06:20 PDT 2008
We deploy a solution like this, where we have a 'main' binary of the
application and a 'startup' binary (it's sort of the app-as-a-service
paradigm too).
The main binary resides in libexec, whereas the startup binary is normally
accessible trough $PATH. When the user invokes the startup binary and the
main app already runs (D-Bus name exists), it does nothing, otherwise it
starts the main binary using D-Bus activation, and already starts checking
in a NameOwnerChanged callback whether its bus name was acquired and lost;
by this means we are able to track application crashes during D-Bus
activation.
Once the main app has started, it emits a StartupComplete signal on the bus,
by which the 'startup' binary knows the app has successfully started, and it
(the startup binary) can now further proceed (this is implemented using a
GLib mainloop running until the StartupComplete signal has been received,
or, as already described, the bus name had been acquired, but lost before
the StartupComplete signal could be emitted/received).
Once the startup binary knows the main binary is running it will, depending
on CLI arguments, perform further actions on one of the app's interfaces
(it's a media player so possible actions are play files, or asking it to
quit).
Furthermore, a 'sentinel' process is started, which watches the main app and
checks on its status; this is meant to provide a gdb backtrace in case of a
crash, although we weren't able to make this work successfully yet; the
sentinel is also able to detect a crash in case the bus name of the main app
is lost, but a ShutdownComplete signal, which it emits on a clean exit, has
not been received yet.
Reference:
http://hg.backtrace.info/hgwebdir.cgi/mpx/file/1cc4ad52d52b/remote/mpx.cc
2008/8/8 Soh Kam Yung <sohkamyung at gmail.com>
> On Thu, Aug 7, 2008 at 6:19 PM, Thiago Macieira <thiago at kde.org> wrote:
> > On Thursday 07 August 2008 11:53:52 Soh Kam Yung wrote:
> >>
> >> Just to be certain, by unique ID, you mean the return value from
> >> dbus_message_get_sender()?
> >
> > I meant "the unique ID that the bus gives your connection when you
> connect
> > (the response to the Hello call)", which can be obtained via
> > dbus_bus_get_unique_name().
> >
> > That's the definition of it.
> >
> > But dbus_message_get_sender() returns that too, on *received* messages.
> >
>
> Thanks for the clarifications.
>
> Regards,
> Kam-Yung
> --
> Soh Kam Yung
> my Google Reader Shared links:
> (http://www.google.com/reader/shared/16851815156817689753)
> my Google Reader Shared SFAS links:
> (http://www.google.com/reader/shared/user/16851815156817689753/label/sfas)
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20080808/f2534704/attachment.htm
More information about the dbus
mailing list