Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

[Wolfgang Hommel]

Hi Ben,

thanks for reporting this. Please be advised that a newer release is 
available upstream, which however likely is not related to your issue.


With your calls, you should not use the '-f' parameter. Without '-f', 
the timestamp is passed on to date/gdate for parsing, which yields the 
following for me on Debian Buster x86_64:



./faketime '2019-09-06 03:14:37 02:00' /bin/date
date: invalid date ‘2019-09-06 03:14:37 02:00’
Error: Timestamp to fake not recognized, please re-try with a different 
timestamp.


./faketime '2019-09-06T03:14:37+02:00' /bin/date
Fri 06 Sep 2019 03:14:37 AM CEST


So the "iso-strict" variant seems to work out of the box.


When using '-f', the specified string is directly passed on to 
libfaketime by the 'faketime' wrapper without parsing (using 
date/gdate). In this case, you either have to stick to one of the 
formats that libfaketime expects (as documented in the README at 
https://github.com/wolfcw/libfaketime), or, which might be more 
appropriate for your case, you also have to set the FAKETIME_FMT 
environment variable.


I hope that helps a bit.

I also agree that "Success" isn't much of a useful error message here. 
In this case, it's created by a call to the standard perror() system 
call, which should be considered to be replaced with something more 
meaningful. I'll put that on the todo list. :-) However, more useful 
error messages are printed by the wrapper when '-f' is not used.



Best regards
Wolfgang


Ben Wiederhake wrote on 08.09.19 20:54:

Package: faketime
Version: 0.9.7-3
Severity: normal

Dear Maintainer,

I've tried to use faketime to build something reproducibly, by using the git
commit time.
Git offers shortcuts for the formats "iso" (e.g. "2019-09-06 03:14:37 +0200")
and "iso-strict" (e.g. "2019-09-06T03:14:37+02:00").

Steps to reproduce, and actual behavior in bash:

$ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true  # "iso"
[$? = 0]
$ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true  # "iso-strict"
Failed to parse FAKETIME timestamp: Success
[$? = 1]

Expected behavior: Either the second invocation should "just work",
or produce a more meaningful error message.

I prefer the first behavior, and "Success"
sounds like the parsing actually worked, just got handled wrongly,
so maybe this can be done easily?

For my little thing I'll just use git's "iso" shortcut.

Cheers,
Ben Wiederhake



-- System Information:
Debian Release: bullseye/sid
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages faketime depends on:
ii  libc62.28-10
ii  libfaketime  0.9.7-3

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#907264: faketime: timezone bugs: lax parsing, no way to specify UTC or TZ

[Wolfgang Hommel]

Ian,

thanks for the detailed report, which is clearly to confirm.

libfaketime internally relies on strptime() to parse the user-specified 
timestamp.



On current macOS, your examples work reasonably well in the following 
variation:


$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0200' gdate -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0300' gdate -R

Tue, 26 Jun 2018 08:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0400' gdate -R

Tue, 26 Jun 2018 07:00:03 +0200


Whereas on Debian, with the glibc implementation of strptime, we end up 
with your results:


$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0200' date -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0300' date -R

Tue, 26 Jun 2018 09:00:03 +0200

$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26 09:00:03 
+0400' date -R

Tue, 26 Jun 2018 09:00:03 +0200


Apparently, glibc goes for a new tm->tm_gmtoff field and supports %z 
(but not %Z) fully yet. This might give some headaches regarding 
cross-platform compatibility, and implementing a completely own parser 
(i.e., not using strptime()) does not seem viable, either. So yes, this 
needs to be addressed, but will take some time.



As a workaround, you can throw anything at libfaketime what `date` can 
interpret, as in


$ LD_PRELOAD=./libfaketime.so.1 FAKETIME_FMT=%s FAKETIME="`date +%s 
-d'2018-06-26 09:00:03+0400'`" date -R

Tue, 26 Jun 2018 07:00:03 +0200


Best regards,
Wolfgang

Bug#875760: Timestamp to fake not recognized for "faketime "+1" stat foo"

[Wolfgang Hommel]

So far, this is intentional behavior of the wrapper script.

Use the command line switch -f, then it should work just as you expect:

faketime -f "+10" stat foo

should do.

Bug#811610: [PATCH] Disable the nonnull-compare flag for faketime.

[Wolfgang Hommel]

Hi Daniel, Mike,

thanks for your analysis, which is pretty much complete from my 
perspective.


In the functions intercepted by libfaketime, we need to ensure that the 
"offending" parameter is indeed non-NULL, and although this may be the 
enforced case in the future when everything on the system is 
gcc6-compiled, we can't rely on that assumption in a cross-platform way 
at the moment. Other ways of handling gcc6 and __THROW__nonnull would 
require gcc6-specific code in each of the stat()-family functions, so 
suppressing the check using -Wno-nonnull-compare is the best solution 
for the moment. Thanks for the patch!



Cheers,
Wolfgang

Daniel Kahn Gillmor 
7 July 2016 at 19:19
Hi Mike--

Thanks for this analysis and the proposed fix! I think the issue here
is that faketime is providing a wrapper around stat(), and stat itself
has undefined behavior if it was passed a NULL pointer.

So arguably, in normal code, we would propagate the "undefined behavior"
out through faketime's wrapper of stat.

However, faketime's wrapper is called through LD_PRELOAD, so no compiler
would notice such a marking anyway.

So at the moment, i think your conclusion is the right workaround for
debian, and i'll upload something like it shortly.

However, upstream (Hi Wolfgang on Cc!) might view this differently.
Wolfgang, do you want to propose a different way to make faketime build
cleanly with GCC 6?

--dkg
Mike Gerow 
7 July 2016 at 11:59
Proposing this patch to just disable the warning. Not super familiar
with the general policies around this, though.

---
debian/changelog | 7 +++
debian/rules | 6 ++
2 files changed, 13 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9cb8901..535de0c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+faketime (0.9.6-4.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable the nonnull-compare flag for faketime.
+
+ -- Mike Gerow  Thu, 07 Jul 2016 11:36:54 +0200
+
faketime (0.9.6-4) unstable; urgency=medium

* link to libfaketime's README from faketime's doc dir (thanks, Ximin
diff --git a/debian/rules b/debian/rules
index cf3813a..1cd0399 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,12 @@

export DEB_CFLAGS_MAINT_APPEND=-DMULTI_ARCH

+# GCC 6 includes a warning for checking if a variable nonnull if it's 
been
+# tagged that passing a NULL value creates undefined behavior. Ignore 
this for
+# faketime since the compilation units that define this for it are in 
libc,

+# which may or may not have these flags.
+export CFLAGS+=-Wno-nonnull-compare
+
# make sure dh_makeshlibs does not modify post{inst,rm} scripts:
# (avoids lintian's postinst-has-useless-call-to-ldconfig)
override_dh_makeshlibs:

Bug#753461: faketime stable breaks iceweasel 24.6

[Wolfgang Hommel]

Charles,

it's hard to comment this profoundly without giving it some serious and 
time-consuming debugging first. Anyway, I assume that your problem 
persists with both offsets and start-at dates even when 
LD_PRELOADing libfaketime directly, i.e., without the faketime wrapper.


In this case, the observed behavior is quite typical for applications 
which load system libraries (including time-related functions) 
themselves at run-time. It basically means that the LD_PRELOAD mechanism 
is somewhat bypassed by the application, which loads the real (not the 
faking) library again after the linker has loaded the faking library. 
Strange things (such as slow reactions with few-seconds-offsets or 
endless hangs with larger offsets) occur when the application is 
multi-threaded and one thread sees a faked time while another one uses 
the real system time, and both try to synchronize.


If that's the case with iceweasel (idk for sure atm), there's nothing 
libfaketime can do because that's a limitation of the LD_PRELOAD 
mechanism. This is what makes faketime unusable with a few complex 
runtime environments, such as the Sun Java JDK/JRE, and there currently 
are no stable solutions known except for making the application 
explicitly libfaketime-aware. That said, unless we figure out that this 
is a libfaketime-internal bug and not a LD_PRELOAD limitation, there's 
little hope that it can be changed anytime soon. I'd actually be very 
happy about any suggestions on what to change about libfaketime to make 
it work with such applications.






Charles Evans mailto:charlesev...@chartertn.net
5. August 2014 19:08
On Sun, 13 Jul 2014 20:21:00 -0400
snip

(I answered this many days ago, but it seems to have vanished.
possibly not the only email I sent to do so.)

The problem is with offset timing:
faketime -m -f -1s iceweasel
sets the clock to appear to run 1s behind.
the -f +1s and -f -1s cause problems.

BTW I updated to the backport Version: 0.9.6-1~bpo70+1
and it still has many of the same problems:
-1s pegs 2 cores at 100% forever.
+1s makes large menus that scroll do so extremely slowly.

Bug#699559: faketime: segfaults with libc 2.17

[Wolfgang Hommel]

Daniel,

for further analysis, you may want to search  replace any occurrences of

RTLD_NEXT

by

dlopen(/lib/librt.so.1, RTLD_NOW)

in faketime.c ; this is ugly (not only due to the hardcoded path), but 
it may avoid issues with RTLD_NEXT going sideways.


Although I don't know why libc6 2.17-0experimental0 behaves this way, I 
take it as a suggestion to add some more checks to avoid endless recursion.



Best regards,
Wolfgang


Daniel Kahn Gillmor wrote:

( cc'ing upstream as well -- wolf, this is in regards to the faketime
bug report http://bugs.debian.org/699559 )



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#495630: ITP: libfaketime -- report faked system time to programs

[Wolfgang Hommel]

Daniel, Matthias,

admittedly I haven't been aware of datefudge so far; seems to me like 
both mini-tools have been developed independent of each other since 
around 2003.


From looking at datefudge 1.14 (is that the most recent version?), I'd 
claim that libfaketime currently provides a superset of the 
functionality, but as you already wrote, datefudge will do for many 
purposes.


Actually, if you could point out in more detail how you'd like 
libfaketime to be enhanced, e.g. how the time specification syntax could 
be improved from your perspective, I'm certainly interested in working 
on that. I didn't find libfaketime's syntax so different from your 
datefudge example call, but maybe I'm missing something here.


On the other hand, this means that I would stick to libfaketime as my 
code base, and I think that matches Matthias' preferences as well. It 
certainly shouldn't hurt to have more than one tool to choose from (of 
course, that's my personal opinion, and might not match Debian's package 
policies).



Best regards,
Wolfgang

Daniel Kahn Gillmor schrieb:

This is in reference to my proposal to package libfaketime for debian,
found here:

  http://bugs.debian.org/495630
  





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]