From: Zev Weiss <zev@bewilderbeest.net>
To: libc-alpha@sourceware.org
Cc: openbmc@lists.ozlabs.org, Wayne Tung <wayne.tung@ui.com>
Subject: nscd time_t size mismatch problem
Date: Tue, 25 Oct 2022 12:54:51 -0700 [thread overview]
Message-ID: <Y1g/C4pinQ1tutC4@hatter.bewilderbeest.net> (raw)
Hello glibc devs,
We've recently been seeing some misbehavior from nscd in OpenBMC. It
manifests as lots of log messages like:
disabled inotify-based monitoring for file /passwd': No such file or directory
stat failed for file /passwd'; will try again later: No such file or directory
disabled inotify-based monitoring for file /group': No such file or directory
stat failed for file /group'; will try again later: No such file or directory
disabled inotify-based monitoring for file /hosts': No such file or directory
stat failed for file /hosts'; will try again later: No such file or directory
disabled inotify-based monitoring for file /resolv.conf': No such file or directory
stat failed for file /resolv.conf'; will try again later: No such file or directory
and so forth. I initially assumed it was a configure-time --sysconfdir
mixup, but after digging into it I found that it actually stems from a
time_t size mismatch (this is a 32-bit ARM gnueabi target):
$ gdb -batch -ex 'pt time_t' -ex 'p sizeof(time_t)' time/time.o
type = long
$1 = 4
$ gdb -batch -ex 'pt time_t' -ex 'p sizeof(time_t)' nscd/nscd.o
type = long long
$1 = 8
The confusing log messages are thus just the result of the coincidence
that sizeof(long long) - sizeof(long) == strlen("/etc"), which causes
the disagreement in the layout of struct traced_file to make it look
like the 'fname' member just had its directory prefix chopped off.
In the discussion of the bug in the OpenBMC issue tracker [0], Wayne
Tung (CCed) came up with the patch below, which does seem to solve the
immediate problem, but if I'm understanding things right does so by just
reverting nscd to a 32-bit time_t, and so I'd expect probably wouldn't
be considered the "right" fix -- however I don't presently know enough
about the 32/64-bit time_t transition and ensuing compatibility concerns
to know what the right fix really is. Should nscd perhaps be using
__time64_t or something instead of time_t?
Thanks,
Zev Weiss
[0] https://github.com/openbmc/openbmc/issues/3881
From 0fda9faf757abd4f5469e6d9207499e97f79a663 Mon Sep 17 00:00:00 2001
From: Wayne Tung <wayne.tung@ui.com>
Date: Thu, 13 Oct 2022 13:10:21 +0800
Subject: [PATCH] Use 32 bits time_t for ncsd
---
Makeconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makeconfig b/Makeconfig
index 47db08d6ae..f78f7cc74a 100644
--- a/Makeconfig
+++ b/Makeconfig
@@ -869,7 +869,7 @@ endif
+extra-math-flags = $(if $(filter libm,$(in-module)),-fno-math-errno,-fmath-errno)
# Use 64 bit time_t support for installed programs
-installed-modules = nonlib nscd lddlibc4 ldconfig locale_programs \
+installed-modules = nonlib lddlibc4 ldconfig locale_programs \
iconvprogs libnss_files libnss_compat libnss_db libnss_hesiod \
libutil libpcprofile libSegFault
+extra-time-flags = $(if $(filter $(installed-modules),\
--
next reply other threads:[~2022-10-25 19:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 19:54 Zev Weiss [this message]
2022-10-25 21:13 ` nscd time_t size mismatch problem Adhemerval Zanella Netto
2022-10-26 1:04 ` Zev Weiss
2022-10-26 11:31 ` Adhemerval Zanella Netto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1g/C4pinQ1tutC4@hatter.bewilderbeest.net \
--to=zev@bewilderbeest.net \
--cc=libc-alpha@sourceware.org \
--cc=openbmc@lists.ozlabs.org \
--cc=wayne.tung@ui.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.