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 > 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. 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 configuration). 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
