Re: [PATCH BlueZ 1/6] share/mainloop: Add handling of NOTIFY_SOCKET

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Marcel,
On Mon, Nov 26, 2018 at 7:55 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Luiz,
>
> > This adds handling of systemd NOTIFY_SOCKET so application using
> > mainloop instance do properly notify systemd what is their state.
> > ---
> > Makefile.am                  |   8 ++-
> > src/shared/mainloop-glib.c   |   8 +++
> > src/shared/mainloop-notify.c | 104 +++++++++++++++++++++++++++++++++++
> > src/shared/mainloop-notify.h |  25 +++++++++
> > src/shared/mainloop.c        |  12 ++++
> > src/shared/mainloop.h        |   1 +
> > 6 files changed, 156 insertions(+), 2 deletions(-)
> > create mode 100644 src/shared/mainloop-notify.c
> > create mode 100644 src/shared/mainloop-notify.h
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 0b26ccc3e..124c32482 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -130,12 +130,16 @@ endif
> > src_libshared_glib_la_SOURCES = $(shared_sources) \
> >                               src/shared/io-glib.c \
> >                               src/shared/timeout-glib.c \
> > -                             src/shared/mainloop-glib.c
> > +                             src/shared/mainloop-glib.c \
> > +                             src/shared/mainloop-notify.h \
> > +                             src/shared/mainloop-notify.c
> >
> > src_libshared_mainloop_la_SOURCES = $(shared_sources) \
> >                               src/shared/io-mainloop.c \
> >                               src/shared/timeout-mainloop.c \
> > -                             src/shared/mainloop.h src/shared/mainloop.c
> > +                             src/shared/mainloop.h src/shared/mainloop.c \
> > +                             src/shared/mainloop-notify.h \
> > +                             src/shared/mainloop-notify.c
> >
> > if ELL
> > src_libshared_ell_la_SOURCES = $(shared_sources) \
> > diff --git a/src/shared/mainloop-glib.c b/src/shared/mainloop-glib.c
> > index 8436969bb..9d588e8c5 100644
> > --- a/src/shared/mainloop-glib.c
> > +++ b/src/shared/mainloop-glib.c
> > @@ -36,6 +36,7 @@
> > #include <glib.h>
> >
> > #include "mainloop.h"
> > +#include "mainloop-notify.h"
> >
> > static GMainLoop *main_loop;
> > static int exit_status;
> > @@ -43,6 +44,7 @@ static int exit_status;
> > void mainloop_init(void)
> > {
> >       main_loop = g_main_loop_new(NULL, FALSE);
> > +     mainloop_notify_init();
> > }
> >
> > void mainloop_quit(void)
> > @@ -70,11 +72,17 @@ int mainloop_run(void)
> >       if (!main_loop)
> >               return -EINVAL;
> >
> > +     mainloop_notify("READY=1");
> > +
> >       g_main_loop_run(main_loop);
> >
> > +     mainloop_notify("STOPPING=1");
> > +
>
> I actually think this is too simple. Frankly what we want is some generic code that runs the mainloops and handles the terminations signals and also brings you onto D-Bus. And only then signal READY=1.

That was the intention, though things like btmon-logger does not need
to be on D-Bus beside mainloop_run is normally called after D-Bus
setup since we want to confirm we can claim the name.

> If you look at iwd and wired/dbus.c then I have started something in that direction with dbus_app_run. That needs to be a bit more unified and turned into l_dbus_run or some similar name.

Right, Im not sure if that applies to our internal g_dbus though but
for meshd it definitely makes sense.

> My thinking really is that the main() function should be just deal with argument parsing and then getting you on the system or session bus. It should not be bothered with all the signal setup or the duplicated code for handling the asynchronous shutdown. And if you have that, then you do a nice integration with NOTIFY_SOCKET.

I just wanted to tackle READY=1 and STOPPING=1 when the mainloop start
and stop respectively, those I think make sense regardless of what
type of service (D-Bus daemon, btproxy, btattach, etc) but perhaps you
are saying that those things may actually need to be notified in
different places depending on the service.

For READY=1 I can see the point if the service does require do to
something asynchronous before it is considered ready, bluetoothd
currently don't require that but maybe in ell we are doing something
different, for STOPPING=1 that only indicates we are starting to
shutdown so that doesn't rule out doing it asynchronously:

https://www.freedesktop.org/software/systemd/man/sd_notify.html

STATUS= is free format and given the example I was assuming if would
notify things asynchronously if we have to, thus why I created
mainloop_notify, perhaps we should rename it to
mainloop_notify_status?

Watchdog I guess it is pretty safe to do the handling along with the
mainloop since timeout handling is already done there anyway, anyway
notifying READY or STOPPING multiple times probably don't make any
sense, they cannot be undone, we could perhaps have a flag indicating
if the mainloop shall handle those, maybe via an option like
-s/--service=[ready, stopping, watchdog] passed to mainloop_init(int
argc, char *argv[]) that way the user can inform that he wants to run
the tool as a service and optionally include what states it should
control (by default it would be all).

> Regards
>
> Marcel
>


-- 
Luiz Augusto von Dentz