Hi Marcel,
On Tue, Nov 27, 2018 at 3:30 PM Marcel Holtmann <marcel@xxxxxxxxxxxx> 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.
>
> I think it is fine to have a version that does not connect to D-Bus, but the name claiming in case of D-Bus based application needs to be handled correctly as well. The background is that we want to start other activities like connecting to mgmt socket etc. only _after_ we successfully claimed the name. Claiming the name is an asynchronous operation (at least in ELL D-Bus) so the mainloop needs to be running.
As I said Im fine not triggering the READY=1 directly at mainloop_run,
the name claim is done blocking in gdbus/libdbus but Id understand
this may change once we switch over to ELL.
> >> 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.
>
> Our internal gdbus is something that needs to move towards ELL D-Bus really quickly. We have to remove the dependency on libdbus even if we keep gdbus API in place for a while.
>
> >> 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).
>
> The watchdog needs to be done within the mainloop since you have to have timeout handling active.
>
> We can argue about if certain things are useful as a short term quick solution, but in the end we want a proper solution and not just hack it into the codebase. I rather have no systemd integration than a half-baked one.
Well Im trying to agree here on the API so we can have it similar in
ELL thus making the transition a bit simpler, I was already intending
to switch everything to mainloop abstraction, since I suppose the
problem with ELL is not exactly the API but the dependency which may
not be available in many distros. Some people already experience this
on the likes of rpi when attempting to use meshd, though we hope that
makes distro guys attempt to create packages for it once we have the
D-Bus APIs implemented.
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
