URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: opened
PR body: """ If sssd_nss starts up while the filesystem where the memcache files will reside (SSS_NSS_MCACHE_DIR) does not have sufficient space, sssd_nss can be killed by SIGBUS while attempting to write to the mmap()'d address space.
Replace the ftruncate() call with posix_fallocate(), which will fail in this scenario, so we can detect the condition and continue startup without the memcache functionality.
Fixes #5369 """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ With the repro described on the ticket, we now observe the failures in sssd_nss.log but sssd_nss successfully starts up without memcache functionality. ``` (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0100): Fast 'PASSWD' mmap cache: timeout = 300, slots = 209712 (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0020): Failed to allocate file /var/lib/sss/mc/passwd: 28(No space left on device) (2020-10-14 16:05:59): [nss] [setup_memcaches] (0x0020): Failed to initialize passwd mmap cache: 'No space left on device' (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0100): Fast 'GROUP' mmap cache: timeout = 300, slots = 157284 (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0020): Failed to allocate file /var/lib/sss/mc/group: 28(No space left on device) (2020-10-14 16:05:59): [nss] [setup_memcaches] (0x0020): Failed to initialize group mmap cache: 'No space left on device' (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0100): Fast 'INITGROUPS' mmap cache: timeout = 300, slots = 262140 (2020-10-14 16:05:59): [nss] [sss_mmap_cache_init] (0x0020): Failed to allocate file /var/lib/sss/mc/initgroups: 28(No space left on device) (2020-10-14 16:05:59): [nss] [setup_memcaches] (0x0020): Failed to initialize initgroups mmap cache: 'No space left on device' ``` ``` sudo systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/lib/systemd/system/sssd.service; disabled; vendor preset: enabled) Active: active (running) since Wed 2020-10-14 16:05:59 GMT; 5min ago Main PID: 17576 (sssd) Tasks: 3 (limit: 2362) CPU: 65ms CGroup: /system.slice/sssd.service ├─17576 /usr/sbin/sssd -i --logger=files ├─17577 /usr/libexec/sssd/sssd_be --domain foo --uid 0 --gid 0 --logger=files └─17578 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files ``` """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-708518591
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ A couple of remarks: - `ftruncate` [promises](https://pubs.opengroup.org/onlinepubs/9699919799/functions/ftruncate.html) "If the file size is increased, the extended area shall appear as if it were zero-filled." While it's natural to expect the same from `posix_fallocate`, I can't find explicit confirmation in the docs... - [glibc docs](https://www.gnu.org/software/libc/manual/html_node/Storage-Allocation.html) say: "such pre-allocation may not reliably prevent the out-of-disk-space error from occurring later. Checking for write errors is still required, and writes to memory-mapped regions created with mmap can still result in SIGBUS." But perhaps this is still better than `ftruncate`... """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-708564631
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ A couple of remarks: - `ftruncate` [promises](https://pubs.opengroup.org/onlinepubs/9699919799/functions/ftruncate.html) "If the file size is increased, the extended area shall appear as if it were zero-filled." While it's natural to expect the same from `posix_fallocate`, I can't find explicit confirmation in the docs... - [glibc docs](https://www.gnu.org/software/libc/manual/html_node/Storage-Allocation.html) for `posix_fallocate` say: "such pre-allocation may not reliably prevent the out-of-disk-space error from occurring later. Checking for write errors is still required, and writes to memory-mapped regions created with mmap can still result in SIGBUS." But perhaps this is still better than `ftruncate`... """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-708564631
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Another thing to consider is that `posix_fallocate` will fail for some file systems, for example NFS.
(This specific example perhaps doesn't matter as I guess there is no sane reason to place mem-cache on NFS, but still)
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-708569579
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Thank you for your inputs @alexey-tikhonov.
I think you are correct that we cannot rely on the file appearing zero filled following a call to `posix_fallocate()`. There could then be a small race where a client does not treat the cache file as [un-initialised](https://github.com/SSSD/sssd/blob/b913ddbd5aec9ea87ddbf10dd09299edd87854dd/s...). To prevent this, we could perhaps write `MC_HEADER_SIZE` zero bytes to the file and then use `posix_fallocate()` for the remainder.
On the concern over the note in the glibc docs, the most obvious way I can see this manifesting is when working with copy-on-write cloned files, which we aren't doing here (however I guess there are other scenarios). It's also not clear if this note relates only to the emulated behaviour of `posix_fallocate()`. I think it's fair to say that the general behaviour of `posix_fallocate()` is closer to what we need than `ftruncate()`, even with this caveat.
An alternative approach would be to use `fallocate(2)` with `FALLOC_FL_ZERO_RANGE`. However since this is Linux specific, and `FALLOC_FL_ZERO_RANGE` is filesystem dependent we would need a portable fallback (unless it's acceptable to disable the memcache in this scenario).
The last, and probably most portable, approach would be to catch and gracefully handle SIGBUS. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709164015
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """
Another thing to consider is that posix_fallocate will fail for some file systems, for example NFS.
My understanding is that `posix_fallocate` will fallback to an emulated mode if the filesystem doesn't support `fallocate`. There are caveats to that (in the linked glibc docs), but I don't think they would be concerns for us since there is only one writer and we don't use `O_WRONLY` or `O_WRONLY`. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709179643
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """
Another thing to consider is that posix_fallocate will fail for some file systems, for example NFS.
My understanding is that `posix_fallocate` will fallback to an emulated mode if the filesystem doesn't support `fallocate`. There are caveats to that (in the linked glibc docs), but I don't think they would be concerns for us since there is only one writer and we don't use `O_WRONLY` or `O_APPEND`. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709179643
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
I think you are correct that we cannot rely on the file appearing zero filled following a call to `posix_fallocate()`. There could then be a small race where a client does not treat the cache file as [un-initialised](https://github.com/SSSD/sssd/blob/b913ddbd5aec9ea87ddbf10dd09299edd87854dd/s...).
Yes, this is what I was thinking about. On the other hand: even taking into account `fallocate` (used under the hood on Linux systems) doesn't initialize allocated FS blocks, what else could `read` return if not zeros? I mean FS "knows" blocks aren't initiated and thus will not read garbage left on the disk (would be a security threat). Would be good to find a confirmation :) I wouldn't like to complicate things without a reason.
On the concern over the note in the glibc docs, the most obvious way I can see this manifesting is when working with copy-on-write cloned files, which we aren't doing here (however I guess there are other scenarios). It's also not clear if this note relates only to the emulated behaviour of `posix_fallocate()`. I think it's fair to say that the general behaviour of `posix_fallocate()` is closer to what we need than `ftruncate()`, even with this caveat.
Agree. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709471668
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Another thing to consider is that posix_fallocate will fail for some file systems, for example NFS.
My understanding is that `posix_fallocate` will fallback to an emulated mode if the filesystem doesn't support `fallocate`.
Right, indeed.
Btw, `posix_fallocate` can return `EINTR` but perhaps handling this would be too nitpicky :) """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709476096
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
simo5 commented: """
I think you are correct that we cannot rely on the file appearing zero filled following a call to `posix_fallocate()`. There could then be a small race where a client does not treat the cache file as [un-initialised](https://github.com/SSSD/sssd/blob/b913ddbd5aec9ea87ddbf10dd09299edd87854dd/s...).
Yes, this is what I was thinking about. On the other hand: even taking into account `fallocate` (used under the hood on Linux systems) doesn't initialize allocated FS blocks, what else could `read` return if not zeros? I mean FS "knows" blocks aren't initiated and thus will not read garbage left on the disk (would be a security threat). Would be good to find a confirmation :) I wouldn't like to complicate things without a reason.
Certainly you won't get random disk sectors out of it, and in case of mmap new memory pages are always zeroed before handling them to the user process, so you can bet that all this space is intialized to zero. (If you have doubts write a simple test program to check it :-)
On the concern over the note in the glibc docs, the most obvious way I can see this manifesting is when working with copy-on-write cloned files, which we aren't doing here (however I guess there are other scenarios). It's also not clear if this note relates only to the emulated behaviour of `posix_fallocate()`. I think it's fair to say that the general behaviour of `posix_fallocate()` is closer to what we need than `ftruncate()`, even with this caveat.
Agree.
+1
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709481365
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
simo5 commented: """
Another thing to consider is that posix_fallocate will fail for some file systems, for example NFS.
My understanding is that `posix_fallocate` will fallback to an emulated mode if the filesystem doesn't support `fallocate`.
Right, indeed.
Btw, `posix_fallocate` can return `EINTR` but perhaps handling this would be too nitpicky :)
I would handle it, it's not hard, and can really happen on busy systems. Not handling it can lead to heisenbugs that are hard to figure out later. If handling is too hard then a log should be emitted that allows to understand the nature of the failure. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709482400
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Hmm thinking this over again I guess the reason why the docs do not explicitly refer to the file being zero'd, or appearing zero'd, is to account for the case where the operation is performed on an existing file with data. `fallocate(2)` does allude to this:
Any subregion within the range specified by offset and len that did not contain data before the call will be initialized to zero
which makes sense, and a quick test program confirms this, a previously empty file appears zero'd after `posix_fallocate()` while a file previously containing data appears extended/filled with zeros.
So given we use `O_EXCL` and have a new empty file, it should always appear entirely zero'd to us. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709975066
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Re. `EINTR` handling, we should emit a critical log along the lines of `Failed to allocate file foo: 4(Interrupted system call)`. On return of `EINTR`, I think our only other option would be to retry the whole operation. So I can update this to retry n times on `EINTR` if that's preferred? """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-709977780
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
simo5 commented: """ It would be nicer to retry, operating w/o the cache is a very degraded operation mode. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-710471490
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Updated to perform up to two retries of `posix_fallocate` on return of `EINTR`. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-712013195
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Thank you for the update. LGTM. I will await CI to finish before ACK'ing. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-712137873
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Hm...
Some tests failed **twice** on fedora-rawhide: ``` FAILED test_memory_cache.py::test_invalidate_user_before_stop - Failed: DID N... FAILED test_memory_cache.py::test_invalidate_users_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_group_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_groups_before_stop - Failed: DID... FAILED test_memory_cache.py::test_invalidate_everything_before_stop - Failed:... ```
May be a coincidence (i.e. not due to this patch) but needs to be checked. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713013151
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Hm...
Some tests failed **twice** on fedora-rawhide:
FAILED test_memory_cache.py::test_invalidate_user_before_stop - Failed: DID N... FAILED test_memory_cache.py::test_invalidate_users_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_group_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_groups_before_stop - Failed: DID... FAILED test_memory_cache.py::test_invalidate_everything_before_stop - Failed:...
May be a coincidence (i.e. not due to this patch) but needs to be checked.
Those tests always fail on rawhide (on-demand run for example: https://sssd-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/sssd-ci-on-demand/2...) but doesn't fail on my laptop or other CI targets...
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713512848
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Hm...
Some tests failed **twice** on fedora-rawhide:
FAILED test_memory_cache.py::test_invalidate_user_before_stop - Failed: DID N... FAILED test_memory_cache.py::test_invalidate_users_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_group_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_groups_before_stop - Failed: DID... FAILED test_memory_cache.py::test_invalidate_everything_before_stop - Failed:...
May be a coincidence (i.e. not due to this patch) but needs to be checked.
Those tests always fail on rawhide (on-demand run for example: https://sssd-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/sssd-ci-on-demand/2...) but doesn't fail on my laptop or other CI targets...
So far I wasn't able to run integration tests in my local rawhide VM.
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713512848
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Hm...
Some tests failed **twice** on fedora-rawhide:
FAILED test_memory_cache.py::test_invalidate_user_before_stop - Failed: DID N... FAILED test_memory_cache.py::test_invalidate_users_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_group_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_groups_before_stop - Failed: DID... FAILED test_memory_cache.py::test_invalidate_everything_before_stop - Failed:...
May be a coincidence (i.e. not due to this patch) but needs to be checked.
Those tests always fail on rawhide (on-demand run for example: https://sssd-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/sssd-ci-on-demand/2...) but doesn't fail on my laptop or other CI targets...
So far I wasn't able to run integration tests in my local rawhide VM to debug this. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713512848
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Those tests doesn't fail for master branch even on rawhide. So weird, but seems it has something to do with the patch... """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713600527
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Hm...
Some tests failed **twice** on fedora-rawhide:
FAILED test_memory_cache.py::test_invalidate_user_before_stop - Failed: DID N... FAILED test_memory_cache.py::test_invalidate_users_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_group_before_stop - Failed: DID ... FAILED test_memory_cache.py::test_invalidate_groups_before_stop - Failed: DID... FAILED test_memory_cache.py::test_invalidate_everything_before_stop - Failed:...
May be a coincidence (i.e. not due to this patch) but needs to be checked.
Those tests always fail on rawhide but doesn't fail on my laptop or other CI targets...
So far I wasn't able to run integration tests in my local rawhide VM to debug this. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713512848
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Thanks for triaging the failure @alexey-tikhonov. I'll try setting up the rawhide test environment and reproducing the failures. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-713693876
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ I have re-produced this on rawhide. As expected (since the failures appear limited to the tests where sssd is killed immediately after the cache is cleared) this change appears to expose a race condition where the receipt of the termination signal is causing the cache clear to be interrupted.
``` (2020-10-23 16:23:34): [nss] [nss_clear_memcache] (0x0400): Clearing memory caches. (2020-10-23 16:23:34): [nss] [sss_mmap_cache_init] (0x0100): Fast 'PASSWD' mmap cache: timeout = 300, slots = 209712 (2020-10-23 16:23:34): [nss] [sss_mmap_cache_init] (0x0020): Failed to allocate file /tmp/sssd-intg.BMBMV1g9/var/lib/sss/mc/passwd: 4(Interrupted system call) (2020-10-23 16:23:34): [nss] [sss_mmap_cache_reinit] (0x0020): Failed to re-initialize mmap cache. (2020-10-23 16:23:34): [nss] [nss_clear_memcache] (0x0020): passwd mmap cache invalidation failed (2020-10-23 16:23:34): [nss] [sbus_issue_request_done] (0x0040): sssd.service.clearMemcache: Error [4]: Interrupted system call (2020-10-23 16:23:34): [nss] [sss_responder_ctx_destructor] (0x0400): Responder is being shut down ``` """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-715453530
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ I've pushed an additional commit which delays the removal of clear_mc_flag until after the clear operation has been completed. This should avoid the observed failure/race, by effectively delaying the exit of sss_cache and giving sssd_nss enough time to complete the operation before SIGTERM is sent.
This is probably not a final solution, and it is unclear why this is only observed in rawhide, I would just like to demonstrate the CI passing.
(please note I will be AFK for the next week or so) """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-715468664
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file Action: edited
Changed field: title Original value: """ nss: Use posix_fallocate() to alloc memcache file """
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Thank you for the investigation, @deastoe. I think you are right and your solution makes sense.
Initially I couldn't understand why `POSIX_FALLOCATE_ATTEMPTS` doesn't help here (SIGTERM handler merely queues `tevent`and doesn't terminate process immediately). It seems the reason is `monitor` is [sending SIGERM repeatedly](https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L1447)
This means `posix_fallocate()` (i.e. `fallocate()`) several times didn't finish in 10 ms. That's very weird, of course... On the other hand, `usleep(10000)` isn't very reliable, of course. It can easily end up with near-to-zero actual sleep time... """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-716487269
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
It seems the reason is `monitor` is [sending SIGERM repeatedly](https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L1447)
This means `posix_fallocate()` (i.e. `fallocate()`) several times didn't finish in 10 ms. That's very weird, of course... On the other hand, `usleep(10000)` isn't very reliable, of course. It can easily end up with near-to-zero actual sleep time...
For a test I increased this timeout to 150000 and this indeed hides the isses: ``` make-intgcheck: success 00:48:22 ci-build-debug/ci-make-intgcheck.log ```
Anyway, I think your fix to remove `CLEAR_MC_FLAG` **after** caches were re-created makes sense. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-716647092
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
For a test I increased this timeout to 150000 and this indeed hides the isses:
make-intgcheck: success 00:48:22 ci-build-debug/ci-make-intgcheck.log
Anyway, I think your fix to remove `CLEAR_MC_FLAG` **after** caches were re-created makes sense.
Thus ACK from my side.
@sumit-bose, would you like to take a look? """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-723997513
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ @deastoe, do you plan any updates here or is this a final version? """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-723997952
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: [WIP] nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ Apologies @alexey-tikhonov, I got caught up with a few other things when I returned.
I've pushed an update to change the use of `open()` with `access()`.
It seems the reason is monitor is sending SIGERM repeatedly
Ah, that explains that! Didn't get time to trace that out. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-724009510
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: edited
Changed field: title Original value: """ [WIP] nss: Use posix_fallocate() to alloc memcache file """
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ It's weird, but seems recent update somehow broke rawhide again... ``` make-intgcheck: failure 00:26:45 ci-build-debug/ci-make-intgcheck.log ``` """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-724598569
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ So it appears sssd is failing to start in the majority of integration test cases. I don't think the last update to this PR triggered the failure, for example a similar set of failures is seen in the rawhide run for #5367.
Can we trigger a re-run somehow? """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725582858
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
deastoe commented: """ So it appears sssd is failing to start in the majority of integration test cases. I don't think the last update to this PR could have triggered the failure, for example a similar set of failures is seen in the rawhide run for #5367.
Can we trigger a re-run somehow? """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725582858
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """ Restarted. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725586730
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
pbrezina commented: """ Rawhide is broken, but it's not related to this patch. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725944810
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Rawhide is broken, but it's not related to this patch.
Indeed. It fails even for `master` branch.
So my ACK and a kind request for a second look are in force. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725991583
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
Rawhide is broken, but it's not related to this patch.
Indeed. It fails even for master branch.
So my ACK and a kind request for a second look are in force. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-725991583
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
pbrezina commented: """ AFAIK `ftruncate` will also set the increased size to 0. Is this something we rely on in memcache? `sss_mmap_cache_init` does not mention this. Otherwise I'm fine with this change. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-726691664
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
pbrezina commented: """ AFAIK `ftruncate` will also set the increased size to 0. Is this something we rely on in memcache? `sss_mmap_cache_init` does not mention this and based on `posix_fallocate` it is unclear if it also initialize to 0 or not. Otherwise I'm fine with this change. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-726691664
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
alexey-tikhonov commented: """
AFAIK `ftruncate` will also set the increased size to 0. Is this something we rely on in memcache? `sss_mmap_cache_init` does not mention this and based on `posix_fallocate` it is unclear if it also initialize to 0 or not.
This was discussed in details starting from https://github.com/SSSD/sssd/pull/5370#issuecomment-708564631 and conclusion was it should be safe, but please feel free to read and see if you are convinced.
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-726707727
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
pbrezina commented: """ My bad, I missed the initial comments. I run some tests and it seems to work fine, I agree with the change. Ack. """
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-732087265
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Label: +Ready to push
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
pbrezina commented: """ Pushed PR: https://github.com/SSSD/sssd/pull/5370
* `master` * 311e2272424f5a31f1bc8bf72b9956cf4e13d7a2 - nss: remove clear_mc_flag file after clearing caches * 4b0bd8455b35d7c2922187129290912c48670485 - nss: Use posix_fallocate() to alloc memcache file
"""
See the full comment at https://github.com/SSSD/sssd/pull/5370#issuecomment-733622892
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Label: +Pushed
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Label: -Accepted
URL: https://github.com/SSSD/sssd/pull/5370 Title: #5370: nss: Use posix_fallocate() to alloc memcache file
Label: -Ready to push
URL: https://github.com/SSSD/sssd/pull/5370 Author: deastoe Title: #5370: nss: Use posix_fallocate() to alloc memcache file Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5370/head:pr5370 git checkout pr5370
sssd-devel@lists.fedorahosted.org