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
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 -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
On (31/01/17 09:57), Jakub Hrozek wrote:
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).
If the application in question is able to reload its configuration files (without restarting), you can issue the reload command to initiate that process. We cannot misuse restart for such purpose.
LS
sssd-devel@lists.fedorahosted.org
-
Fabiano Fidêncio -
Jakub Hrozek -
Lukas Slebodnik