Last Thursday we had a face to face discussion about how
socket-activate services could refresh the confdb before starting.
There were five of us attending the discussion (Pavel Březina, Lukáš
Slebodnik, Simo Sorce, Stephen Gallagher and myself) and the main
focus of the discussion was on what to do in a near-future scenario
where the monitor won't be present anymore.
So, keeping in mind the "no monitor" scenario what has been suggested
by Simo is:
- Have some sort of inotify in the confdb that, when updated, will
trigger the restart of the services. It's really important to note
that we want a way to be notified that the file was changed as a whole
and not trigger several restarts for each small change possible done
in the file;
- There were some ideas suggested about adding a timestamp to the
confdb or a hash of the file (?) in order to keep track of the latest
changes;
- As we will restart the services when notified that the confdb
changes, we have to be more robust when shutting down any service: as
far as I understand/remember it means we must answer the requests
already done while not accepting any new request. It applies pretty
much to any running service at the moment the confdb becomes updated;
- sssd --genconf may be one way to regenerate the confdb and could be
used as ExecPreStart in the SSSD unit.
For the scneario where the monitor is still around Simo suggested to:
- sssd --genconf may be one way to regenerate the confdb (but in the
end we won't do that)
- SSSD will log that the admin must restart SSSD service in order to
have the confdb updated.
I'm really not sure about the technical details of this discussion as
I didn't have time enough to dig into any of the topics I mentioned in
the email.
For those who also where in the meeting, please, politely provide some
feedback on what I've missed, on what you'd like to expand and so on.
Best Regards,
--
Fabiano Fidêncio