Thank you for writing up and sending the notes to the list so that
everyone can follow!
On Mon, Jan 30, 2017 at 03:31:32PM +0100, Fabiano Fidêncio wrote:
Last Thursday we had a face to face discussion about how
socket-activate services could refresh the confdb before starting.
I'm a bit confused what is the scenario from the admin's point of view.
Isn't it expected (and even desirable) to have a well-defined point,
like reloading or restarting the service to re-read the configuration?
Is the use-case we're trying to fix here the first start of a service
(first activation) or a restart after a change to the config after the
service is running?
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
- 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.
systemctl already has the reload action, can't we use that? Looking at
man systemd.unit, there is even PropagatesReloadTo= and From= and
systemd.service manpage documents ExecReload. Can't we let the main sssd
service to call --genconf and propagate the reload to the services (even
if reloading the services might mean restarting them with a fresh
Of course, the question about dropping the pending requests is still
valid, but IMO if the admin is in full control of the reload, the
concern about dropped requests is still much less valid.
> 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
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org