[Bug debuginfod/26125] during debuginfod cache cleanup, try harder to rmdir empty dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=26125 Martin Liska changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #1 from Martin Liska --- All right Frank, do you speak about debuginfod daemon cache or about debuginfod-find cache (/home/marxin/.cache/debuginfod_client/ in my case)? For the latter, I really see empty folders left. The code container removal code: case FTS_DP: /* Remove if empty. */ (void) rmdir (f->fts_path); break; but it's unrachable as the following continue: if (regexec (&re, f->fts_path, 0, NULL, 0) != 0) continue; for e.g. (gdb) p f->fts_path $4 = 0x425350 "/home/marxin/.cache/debuginfod_client/e0d3f78f324d5aeaa35e6e651ac24f9ac52ccdb7" -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/26125] during debuginfod cache cleanup, try harder to rmdir empty dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=26125
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #2 from Mark Wielaard ---
Could we simply always try to remove the parent dir if the file pattern matches
and we do an unlink?
case FTS_F:
if (time(NULL) - f->fts_statp->st_atime >= max_unused_age)
{
unlink (f->fts_path);
/* Remove if now empty. */
(void) rmdir (dirname (f->fts_path));
}
break;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/26125] during debuginfod cache cleanup, try harder to rmdir empty dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=26125 --- Comment #3 from Frank Ch. Eigler --- Yeah, a speculative rmdir is probably just fine. Martin, there is no difference between a pure client cache, and a debuginfod server's own federation cache. They are both exactly the same thing. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Remove remaining nested functions from libdwfl
On Thu, 2020-11-26 at 15:10 +0100, Timm Bäder via Elfutils-devel wrote: > Here are the three patches to remove the three remaining nested > functions from libdwfl/dwfl_segment_report_module.c. Thanks those look good. Pushed. I did add ChangeLog entries and made sure all lines were < 80 chars. Cheers, Mark
[PATCH] debuginfod: Try to remove empty cache dirs.
When unlinking a max_unused_age file also try to rmdir the parent
directory in case it is now empty.
Signed-off-by: Mark Wielaard
---
debuginfod/ChangeLog | 5 +
debuginfod/debuginfod-client.c | 16
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index aaffac7c..4c5e4947 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2020-11-27 Mark Wielaard
+
+ * debuginfod.cxx (debuginfod_clean_cache): Try to rmdir the
+ parent directory when unlinking a max_unused_age file.
+
2020-11-25 Frank Ch. Eigler
* debuginfod.cxx (step_ok_done): Correct typo in prom metric label.
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index a99f3c14..63dcc719 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -69,7 +69,7 @@ void debuginfod_end (debuginfod_client *c) { }
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -328,12 +328,20 @@ debuginfod_clean_cache(debuginfod_client *c,
/* delete file if max_unused_age has been met or exceeded. */
/* XXX consider extra effort to clean up old tmp files */
if (time(NULL) - f->fts_statp->st_atime >= max_unused_age)
-unlink (f->fts_path);
+{
+ unlink (f->fts_path);
+ /* Remove parent dir if now empty. Note that we need a
+ copy of fts_path since dirname will change it. */
+ char *fts_path = strdup (f->fts_path);
+ if (fts_path != NULL)
+(void) rmdir (dirname (fts_path));
+ free (fts_path);
+}
break;
case FTS_DP:
- /* Remove if empty. */
- (void) rmdir (f->fts_path);
+ /* Should never be reached because the regex only matches
+files, so if it is a dir it isn't ours. */
break;
default:
--
2.18.4
[Bug debuginfod/26125] during debuginfod cache cleanup, try harder to rmdir empty dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=26125 --- Comment #4 from Mark Wielaard --- Full patch: https://sourceware.org/pipermail/elfutils-devel/2020q4/003198.html Question is if this can ever cause a race with the creation of a new cache file. Can there be multiple clients trying to create a hex-build-id dir while putting a file in it, that is simultaneously deleted because of max-age plus then the parent dir getting deleted while some other client is testing if the dir exists and/or putting a tmp file there? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/26125] during debuginfod cache cleanup, try harder to rmdir empty dirs
https://sourceware.org/bugzilla/show_bug.cgi?id=26125 --- Comment #5 from Frank Ch. Eigler --- Yeah, I suppose there is that race possibility. One way to fix it is to use something like file locks, such as a flock(2) on a designated file such as $CACHE/cache_clean_interval_s. During aging/cleanup, hold a LOCK_EX. During normal operation (creation of build-id subdirectories & files), hold a LOCK_SH to permit multiple clients to work independently of one another. -- You are receiving this mail because: You are on the CC list for the bug.
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a failed build on builder whole buildset while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/4/builds/640 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: Blamelist: Timm Bäder BUILD FAILED: failed test (failure) Sincerely, -The BuildbotThe Buildbot has detected a failed build on builder whole buildset while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/15/builds/436 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-armhf Build Reason: Blamelist: Timm Bäder BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
