#3020 sssd does not read in configuration file if changed during the last second
Closed: wontfix 8 months ago by pbrezina. Opened 4 years ago by danielschmitz.

Upon startup sssd checks wether it's configuration database is stale or not.
Therefore it compares the lastUpdate entry in the database with the mtime of the configuration file. If they match it considers it's config database to be in sync with the config file and does not update it.

Unfortunately mtime has a resolution of 1 second. If the configuration file was modified less than one second before this check, sssd ignores that modification.

A better check could be based on checksums instead of timestamps.

Fields changed

priority: major => minor

Sorry, the condition under which this bug occurs was stated wrongly. It should be:

If the configuration file was modified less than one second after the last database update, sssd ignores that modification.

This is a ding libs limitation AFAIR.
If I recall correctly we are talking about

int ini_config_changed(struct ini_cfgfile *file_ctx1,
                       struct ini_cfgfile *file_ctx2,
                       int *changed);

which is implemented in ini_fileobj.c. [[BR]]
A comment from the past (I felt it will bite one day...)

  /* Unfortunately the time is not granular enough
     * to detect the change if run during the unit test.
     * In future when a more granular version of stat
     * is available we should switch to it and update
     * the unit test.

So I think the workaround is to pause before restarting SSSD.
Creating a hash might be an option though it will be a bit more work. If help needed with implementing hashing in ding-libs let me know, I can outline what needs to be done and how.

It seems that stat structure should already have nanosecond granularity.

From man fstat():


Since kernel 2.5.48, the stat structure supports nanosecond resolution for the three file timestamp fields. Glibc exposes the nanosecond component of each field using names of the form st_atim.tv_nsec if the _BSD_SOURCE or _SVID_SOURCE feature test macro is defined. These fields are specified in POSIX.1-2008, and, starting with version 2.12, glibc also exposes these field names if _POSIX_C_SOURCE is defined with the value 200809L or greater, or _XOPEN_SOURCE is defined with the value 700 or greater. If none of the aforementioned macros are defined, then the nanosecond values are exposed with names of the form st_atimensec. On file systems that do not support subsecond timestamps, the nanosecond fields are returned with the value 0.

so it might be easy to just add nanosecond field validation into the function.

Fields changed

cc: => lslebodn

Fields changed

rhbz: => todo

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

Metadata Update from @danielschmitz:
- Issue set to the milestone: SSSD Future releases (no date set yet)

3 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

8 months ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

8 months ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4061

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.