settime: How to see effect of e.g. "date -s" at all?

[sdettmer]

Hi,

I'm very new to libfaketime (I'm looking for a way to avoid a test suite that uses settime changes real system time). I'm not sure how to use it correctly, please tell me what I'm doing wrong. I looked to the code and quickly learned that things are really complex...

My first testcase is to spawn a bash, call "date -s PAST" and then see second "date" command showing the date given. I assumed that this is archived via shared memory, but I have to admit that I don't understand how it should work. I see a call to setenv("FAKETIME"), but I think this will set the env of the first date process only and lose all its effect after its exit - the next date process will not see it at all. I also saw there is save_time() function, but its not called by settime. It is called by gettime which confuses me. I guess the feature behind (FAKETIME_SAVE_FILE) is different from what I'm looking for.

What do I do wrongly?

I think settime misses to update the shared memory somehow, but there seems to be no offset style member, so I think maybe it is only for the increment of ticks?

Also I'm not sure what settime should do when working with a fixed or incrementing time, probably return EPERM?

As a quick hack I noticed that I could implement overwriting FAKETIME_TIMESTAMP_FILE (I think overwriting default rc files doesn't sound good), because then no logic change is needed for my particular use case, but I'm afraid it could cause issues?

Here my "test" command:

FAKETIME_COMPILE_CFLAGS="-DFAKE_SETTIME" make clean all # test
LD_PRELOAD=src/libfaketime.so.1 FAKETIME_TIMESTAMP_FILE=$(pwd)/timestamp_file /bin/bash -c 'date -s "2004-02-29 16:21:42" ; date'

that works as I expect it using the following patch (hack):

diff --git a/src/libfaketime.c b/src/libfaketime.c
index 1726a4b..9be4f20 100644
--- a/src/libfaketime.c
+++ b/src/libfaketime.c
@@ -622,7 +622,7 @@ static void next_time(struct timespec *tp, struct timespec *ticklen)
  *      =======================================================================
  */

-static void save_time(struct timespec *tp)
+static void save_time(const struct timespec *tp)
 {
   if ((shared_sem != NULL) && (outfile != -1))
   {
@@ -3380,6 +3380,18 @@ int clock_settime(clockid_t clk_id, const struct timespec *tp) {
   setenv("FAKETIME", newenv_string, 1);
   force_cache_expiration = 1; /* make sure it becomes effective immediately */

+  {
+    FILE *envfile;
+    static char custom_filename[BUFSIZ];
+    (void) snprintf(custom_filename, BUFSIZ, "%s", getenv("FAKETIME_TIMESTAMP_FILE"));
+
+    if ((envfile = fopen(custom_filename, "wt")) != NULL)
+    {
+      fprintf(envfile, "%+f", offset); // TODO make atomic?? add error handling!
+      fclose(envfile);
+    }
+  }
+
   return 0;
 }

I think one issue with my understanding is that I don't cleanly distinguish the "operation modes" of libfaketime. I think it can be static, incrementing and applying an offset; settime could access shared memory to implement first two easily I think, for the third I think an extension of the structure could be needed (and handled everywhere). Even then it's not clear if a libfaketime should return the new time set by date -s when FAKETIME is set to a fixed value, for instance. So if implementing this I think I would need some advice (if this is interesting and feasible at all).

What do you think?

[sdettmer]

Even ntpdate works now:

$ LD_PRELOAD=src/libfaketime.so.1 FAKETIME_TIMESTAMP_FILE=$(pwd)/timestamp_file /bin/bash
$ date -s "1999-01-01 01:00:00"
Fri Jan  1 01:00:00 CET 1999
$ echo "+0.0" > timestamp_file
$ date
Tue Mar 24 21:12:04 CET 2020
$ date -s "1999-01-01 01:00:00"
Fri Jan  1 01:00:00 CET 1999
$ /usr/sbin/ntpdate -u clock.isc.org
24 Mar 21:12:42 ntpdate[28741]: step time server 204.93.207.11 offset 669931942.341774 sec
$ date
Tue Mar 24 21:12:45 CET 2020

[wolfcw]

I'm struggling a bit with understanding your intention, i.e., your libfaketime use case.

The shared memory stuff is basically only for communication between the faketime wrapper and libfaketime itself. It is unlikely that you will need to implement anything related to it if you just want to use libfaketime.

I'm not sure why you assume that your use case would not work with setting the FAKETIME environment variable appropriately. Several users make use of libfaketime as part of their test suites, either through the faketime wrapper or by LD_PRELOAD'ing libfaketime directly and steering it via the environment variables.

Alternatively, you can link your own C program with libfaketime, but still then its fake time settings are remotely controlled via the environment variables and/or related files.

[sdettmer]

Hi!

Thanks for your reply!

I think I gave example use cases, for example: /bin/bash -c 'date -s "2004-02-29 16:21:42" ; date'. Of course this is an artificial minimal example, our applications of course are more complex.

I'm not sure if I understand the FAKETIME environment variable correctly, but to me it seems very limited. Of course simple cases, such as performing a test at a specific point in time in future (2038 test or such) is possible, but complex cases that get and set dates across processes are not. With the exception of the increment time ticks, that works across processes.

I see that settime is handled, but I fail to see how this helps. It sets environment variable, but this is visible only to the process itself (and to its child processes, but only if created afterwards). It is not visible to "siblings" and "parent" processes, even if running in the same libfaketime environment. (and to share fakes time in only the own same process IMHO would not need an environment variable at all; a static variable in libfaketime would be sufficient, I think).

Of course, for simple unit tests this is be fine, but for higher level integration tests for embedded software, server daemons or "black box" style processes I think environment variables are not enough (for same reason that incrementing ticks is using shared memory - to avoid that every process has its "own" counter).

Also I think using "date -s" instead of FAKETIME environment variables also is much sweeter! date supports a lot of times, including things like "yesterday" and such.

For example, with my hack you can launch a shell, from it two xterms, in one you call ntpdate -u clock.isc.org as ordinary user, int the other xterm shell you can check with date.

I could link all test object applications and all test driver applications against libfaketime, but what would this help? Every process structure would see their own time; test driver applications could not check if the test objects accessed the clock correctly, I think?

We consider adding an indirection to settime and friends simply in our application; but then we need to add a networked test interface where the test application can for example inject a faked system time.

Our testsuite has test cases like:

• if NTP fails, "Fallback Control Application" (a daemon) receives "fallback" time from network and sets local clock. The test application is an own independent standalone application (and thus an own process) and needs to check if local clock was correcly set by the Fallback App. The Fallback Application is a system daemon and is normally started via init.d or systemd (and a script, which already sets LD_PRELOAD for other things).
• several application processes run. The test driver process sets clock some years into past and checks if all message processors still respond quickly and still work correctly (to detect if something waits for a specific timestamp instead of MONOTONIC, for example, or discarding its configuration because out of date, check if correctly fail to communicate due to not-yet-allowed SSL/TLS certificates...)
• several applications run. they operate in local time (for possible bad reasons, but we cannot change). Test application sets clock right before summer time (DST) and checks if application handles "the skipped hour" correctly. Then same for the "double hour".
• several application components behave differently on e.g. sundays or bank holidays. Test application needs to iterate every sunday and bank holiday of coming two years and perform a range of checks to ensure that no odd behavior appears on any sunday, and that every bank holiday is detected correctly and such (I'm not an expert at these calendar features at all)

Did I explain use cases well?

[wolfcw]

Thanks, that helped a lot for my understanding and you certainly got a point there.

libfaketime historically started with faking time for single processes and was then extended to include spawned subprocesses. There are a few use cases for LD_PRELOAD'ing it system-wide, with limits. To some extent, the shared memory stuff was intended to create cross-process environments like you describe, but development in this region never went beyond communication between the faketime wrapper and libfaketime yet.

Intercepting settime calls is a more recent development, and further PRs in this area are more than welcome, e.g., if you could extend your patch above with some error handling (e.g., when FAKETIME_TIMESTAMP_FILE is not set at all). However, taking this really further currently has some major challenges, especially when it comes to handling all the system calls that somehow set or touch files' timestamps (file timestamps might not be in your particular focus, but they are for a lot of build / test runs). As far as time-setting system calls are concerned, libfaketime still is very incomplete, which is due to its historic focus on "read only" functions, and this is also the flimsy excuse for the sync-faketime-changes-between-processes issue you ran into. Demand was apparently low in this area so far, but contributions are more than welcome.

Sometimes, it may be easier and better to just change the real time system-wide, and your test cases seem complex enough to justify running them on a VM to avoid hitting a wall with libfaketime. My guess is also that for some tests you'll run your own NTP server to serve arbitrary clock values, and syncing libfaketime settings across machines is currently far away.

As far as the "natural language" parsing skills of GNU date are concerned, the faketime wrapper makes use of them, so maybe that helps for some of the simple tests.

[sdettmer]

Thanks for your detailed response! Yes, I see, of course things evolve. First libfaketime was a special simple tool and it gets more powerful and now users come with even more :) But I think it just proves that libfaketime is a success story. Communicating with a wrapper also is nice via SHM, a test could use this to inject situations (such as clock skews). It could even offer "stop", "next tick" and "continue normal" functions!

I could add error handling, but I'm not sure what to do. fprintf(stderr)? Actually using the file was just a test whether it works at all. I noticed that the file gets a relative value (like "0.0"), which is not accepted by the wrapper (on next start), so it might be not that easy.

As I saw SHM is always present (did I understand correctly?), should be fast, have no "read only filesystem" issues and so on, I though maybe we could consider using it. It would need at least the offset and a flag whether this offset shall be used (when other sources, such as FAKETIME is also set).

In our case currently we do set the system time in a VM and use NTP server (and own proprietary time protocols, for example GPS based) , and you are right, its easier. However, it has disadvantages, too. First, its slow. To "undo fake" we use ntpdate, but this takes several seconds. The fake time is also used in log file time stamps, which is not desired when looking outside the test case (such as the log file of the test runner itself). We even need to re-touch some test result files that are generated with "fake" time. This would also be the case for a libfaketime time, but could be quickly toggled I think.

In practice also for us its bad that clock handling is part of the test framework and always present. For developers this prevents from running tests and programming (with make) in the same VM, because the fake time leads to incomplete builds sometimes and then everything can happen (hard to find sometimes). When you login to a shell, the system timestamp of course also is messed up. And so on.

I also see a complication by the number of supported platforms. I saw that different glibc versions need different handling and so on, probably not easy to test, especially if adding a new call for interception.

Would it, at all, make sense to lets say:

1. extend SHM by offset and flag (=false)
2. when settime is called (and no TICK mode? what else?), calculated offset is saved in SHM and flag is set, otherwise settime returns some error (which one? any suited OS errno I think?)
3. when time is read and flag is set, SHM offset has "priority"

What do you think?

[wolfcw]

I like that 3-step plan. :-)

What I meant by "error handling" is somewhat different: In the specific case discussed above, we need to be aware that FAKETIME_TIMESTAMP_FILE is not necessarily set at all. So the custom_filename created in the patch might be bogus. This is of course fine for a PoC, but to pull it into libfaketime, it'd be good to handle the situation properly if FAKETIME_TIMESTAMP_FILE is not (yet) set.

So far, libfaketime follows a "envvar first" strategy when it comes to settings, i.e., the content of a set FAKETIME environment variable will be used with priority, and files like /etc/faketimerc only serve as a fallback. Newly added functionality should either

• not change such behavior to remain backwards compatible, or
• enable new features only through flags, e.g., like FAKETIME_XRESET does, or
• wrap it in #ifdefs so it can be omitted at compile time.

I'm fine with extensions to the shared memory data, but ideally there also should be ways to influence those settings without requiring libfaketime users to write shm-modifying code on their own. If something envvar- or file-based does not seem appropriate, it would be good to extend the faketime wrapper (e.g., to signal stuff like "stop", "next tick" and so on to running processes).

One caveat with returning errors is that many calling programs don't expect and handle them as one might expect. This gives us long-term biting bugs like #130, so most of the time I'd recommend to stick to return and error values documented in the man pages; if nothing fits, printing an alert to stderr but otherwise failing silently it not elegant, but already served for detecting and fixing a lot of other problems. :-)

[sdettmer]

In the specific case discussed above, we need to be aware that FAKETIME_TIMESTAMP_FILE is not necessarily set at all

OK, I think this is simple:

git show --oneline --stat
02031da hack for #239: if no FAKETIME_TIMESTAMP_FILE in env, do nothing
 src/libfaketime.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

But is such a function really that simple?

(my "make test" hangs even without my change at (Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test), but I didn't looked into).

Also there is at least one open case, namely that the fopen, fprintf or fclose fail. Not sure what is best here (ignore: the users does not want writing to the file, so they made it read-only; or return an error like EPERM so that users "date -s" fails with EPERM, for example). Anyway, strace helps debugging a lot :)

For me it is hard to see how to best control that. Normally someone could argue that when writing to FAKETIME_TIMESTAMP_FILE is supported, why not to writing to ~/rcfile in case its used? Should rcfile be overwritten or not? What if we have only /etc/rcfile, this we normally cannot even write to. Do we create ~/rcfile then? I think there is some logic in that, but also could surprise people a lot. That's why I implemented it only for FAKETIME_TIMESTAMP_FILE, so it is a "sub-feature" of that. People that just are used to use it to point to their custom ~/rcfile then after an update would get surprised by a different behavior, also not so good. Maybe we need an config / variable controlling that ("do write to FAKETIME_TIMESTAMP_FILE or not?), or a new one instead of FAKETIME_TIMESTAMP_FILE to be used here (FAKETIME_WRITABLE_TIMESTAMP_FILE?!). I don't know what fits best in libfaketimes way of handling (I agree that it should be as consistent as possible).

What do you think?

I wouldn't like #ifdefs, because then distributions won't ever see that feature I think. Not sure if a distributions libfaketime sets-DFAKE_SETTIME at all (BTW, README says someone should set CFLAGS, but instead someone better should set FAKETIME_COMPILE_CFLAGS, took me half an hour to find :)).

What do you think?

Issue #130 is interesting, a nice cyclic dependency. If jemalloc overloads using dlsym, then others may break, sure, malloc is just to basic. Don't know if easily possible, but jemalloc should redirect only after full initialization of each other redirector. I don't know how if there is a way to find out that (and it could be that other redirectors only init things on demand, not all at once).

One solution for #130 IMHO is that the user could like libfaketime statically against libc and libdl, so that libfaketime does not use shared malloc=jemalloc (but its static version), breaking the cycle. For the price that you cannot mallocdebug libfaketime. For that use case the opposite is suited I think: link jemalloc statically against libc and libdl (and whatever else it uses). Each solution might need changes to Makefiles or such and might be non-trivial. Or even difficult. For Linux I think this would work well, because Kernel ABI is very very extremely very stable, I don't know for others.

For the "3 step plan" I would need some guidance, like which places I have to look, what variables have to be checked how or such. I did not yet read about the wrapper. And why it is needed, I think all features should work without it anyway?

[wolfcw]

But is such a function really that simple?

Simple is good. :-)

(my "make test" hangs even without my change at (Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test), but I didn't looked into).

Welcome to the world of ugly workarounds for different glibc versions. This is one of the issues we hope to fix by switching to autoconf/automake (#178 and others). So far, flags need to be set manually on affected platforms. Other, better solutions of course are welcome as well.

Also there is at least one open case, namely that the fopen, fprintf or fclose fail. Not sure what is best here (ignore: the users does not want writing to the file, so they made it read-only; or return an error like EPERM so that users "date -s" fails with EPERM, for example). Anyway, strace helps debugging a lot :)

The overall style, so far, was to not let intercepted functions fail if libfaketime can continue despite such internal problems. fprintf to stderr is used in several cases to inform the user about such troubles which may result in deviating from the likely intended result.

For me it is hard to see how to best control that. Normally someone could argue that when writing to FAKETIME_TIMESTAMP_FILE is supported, why not to writing to ~/rcfile in case its used? Should rcfile be overwritten or not? What if we have only /etc/rcfile, this we normally cannot even write to. Do we create ~/rcfile then? I think there is some logic in that, but also could surprise people a lot. That's why I implemented it only for FAKETIME_TIMESTAMP_FILE, so it is a "sub-feature" of that. People that just are used to use it to point to their custom ~/rcfile then after an update would get surprised by a different behavior, also not so good. Maybe we need an config / variable controlling that ("do write to FAKETIME_TIMESTAMP_FILE or not?), or a new one instead of FAKETIME_TIMESTAMP_FILE to be used here (FAKETIME_WRITABLE_TIMESTAMP_FILE?!). I don't know what fits best in libfaketimes way of handling (I agree that it should be as consistent as possible).

Indeed, the usual style would be to introduce another envvar for "do write to FAKETIME_TIMESTAMP_FILE or not?". It's fine to force users to use FAKETIME_TIMESTAMP_FILE in such a case, but getting this file overwritten should explicitly be indicated by the users. It would also be fine to introduce backwards-compatible changes to the envvar's syntax; for example, so far it only contains a filename, but if you optionally add a prefix like "+" to the filename, it's OK to overwrite it.

I wouldn't like #ifdefs, because then distributions won't ever see that feature I think. Not sure if a distributions libfaketime sets-DFAKE_SETTIME at all (BTW, README says someone should set CFLAGS, but instead someone better should set FAKETIME_COMPILE_CFLAGS, took me half an hour to find :)).

Valid point, although we try to stay in contact with several package maintainers at least for the tagged releases, and they usually use the Makefile we provide as a basis. Flags for new features are usually included by default, unless they break backwards compatibility or are known to be only relevant for a small minority of users.

One solution for #130 IMHO is that the user could like libfaketime statically against libc and libdl, so that libfaketime does not use shared malloc=jemalloc (but its static version), breaking the cycle. For the price that you cannot mallocdebug libfaketime. For that use case the opposite is suited I think: link jemalloc statically against libc and libdl (and whatever else it uses). Each solution might need changes to Makefiles or such and might be non-trivial. Or even difficult. For Linux I think this would work well, because Kernel ABI is very very extremely very stable, I don't know for others.

Certainly a short guide / documentation on how to do that would be interesting for affected developers who really need to use both jemalloc and libfaketime during testing, but I don't think this makes a viable solution for all users. Also, there's a myriad of other applications that won't work properly with libfaketime, especially those using more complex runtime environments, due to inherent problems of the LD_PRELOAD approach.

For the "3 step plan" I would need some guidance, like which places I have to look, what variables have to be checked how or such. I did not yet read about the wrapper. And why it is needed, I think all features should work without it anyway?

The wrapper, called faketime, is just a simple and more comfortable way to use libfaketime than setting all the environment variables manually. It's basically the interface for users who want to get up and running quickly without having to read the whole libfaketime docs. I was referring to it here because it is quite simple / straight-forward and a good example of how the shm stuff is currently used. The basic idea was that if there will be extensions like "sending stop / next tick commands via shm", making them available to users (not only developers) via the wrapper would be a good thing.

[sdettmer]

This is one of the issues we hope to fix by switching to autoconf/automake (#178 and others).

Autoconf sounds great! Is it in a branch? I don't understand the ticket, there is something about PR but then some revert? Travis CI works? That's even greater! I worked a lot with autotools in the past, on concrete problems I might be a little help in simple cases, but of course I need to be able to reproduce the issue or have CI result log files.

The overall style, so far, was to not let intercepted functions fail if libfaketime can continue despite such internal problems. fprintf to stderr is used in several cases to inform the user about such troubles which may result in deviating from the likely intended result.

I added that:

c2e45aa hack for #239: settime reports error writing to FAKETIME_TIMESTAMP_FILE`

I tried to align to the style and README.developer, but I'm afraid the style already is mixed. Just tell me how you want it, I'll reformat to whatever is considered most beautiful :)

I implemented a pragmatic version, what do you think:

$ chmod 0 timestamp_file
$ LD_PRELOAD=src/libfaketime.so.1 FAKETIME_TIMESTAMP_FILE=$(pwd)/timestamp_file /bin/bash -c 'date -s "1999-01-01 01:00:00" ; date'
libfaketime: In clock_settime(), failed to to open file while updating FAKETIME_TIMESTAMP_FILE (`/home/sdettmer/work/faketime/libfaketime/timestamp_file'): Permission denied

Please just tell if you like the message being changed.

Indeed, the usual style would be to introduce another envvar for "do write to FAKETIME_TIMESTAMP_FILE or not?". It's fine to force users to use FAKETIME_TIMESTAMP_FILE in such a case, but getting this file overwritten should explicitly be indicated by the users. It would also be fine to introduce backwards-compatible changes to the envvar's syntax; for example, so far it only contains a filename, but if you optionally add a prefix like "+" to the filename, it's OK to overwrite it.

OK, I think I can implement either option easily, but please tell me which one do you prefer. For the first please choose a variable name (for me as newbie its hard to find the right style I guess). If using the prefix "+" (or tell another one, as you like) of course I also need to change the place where it is read. Actually this other place already has a small minor bug, namely in case no FAKETIME_TIMESTAMP_FILE it tries to open a file "(null"):

$ echo "error" >  '(null)'
$ LD_PRELOAD=src/libfaketime.so.1 /bin/date
libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp: Success
Please check specification error with format %Y-%m-%d %T

which I would also fix in that case. Also parse_ft_string() in this place better shouldn't use perror() I think (errno will be OK, so we see that "Success").

What do you think?

about CFLAGS:

Flags for new features are usually included by default, unless they break backwards compatibility or are known to be only relevant for a small minority of users.

Well, at least for "-DFAKE_SETTIME" its not the case and at the moment this is the only one I'm looking at :)

about solution for #130

Certainly a short guide / documentation on how to do that would be interesting for affected developers who really need to use both jemalloc and libfaketime during testing, but I don't think this makes a viable solution for all users.

mmm... I'm not able to get it linking on my machine. I though (adding -fPIC and) linking against something like /usr/lib/x86_64-linux-gnu/libdl.a -lm -lrt -lc_nonshared would work, but it doesn't. Using -lc_nonshared seems to have no visible effect and libdl.a does not link, I only get ´relocation R_X86_64_PC32 against undefined symbol `__dlsym' can not be used when making a shared object; recompile with -fPIC`. If libdl.a is really compiled without -fPIC (and thus position dependent), we would need to recompile it (if this is working at all). Other option would be linking femalloc statically, but I don't have it. Also I wasn't able to get malloc included (file size does no even change), so I think that this maybe does not work either. I googled a lot, but I'm afraid that this is such a rare requirements combination that there are no answers. Maybe someone could ask gcc-users, but for now I'm out of time.

The wrapper, called faketime, is just a simple and more comfortable way to use libfaketime than setting all the environment variables manually.

OK, thanks, I see. A launcher. I think it converts command line options to environment variables, so I would use a shell script instead, could be simpler. It also zero-inits the SHM (in the zero init, two fields are -1, which IMHO is not zero :)). From stomach feeling this is a bit odd to have this here, it this really needed?

Then I would not use the launcher, but make an own little tool, faketimectrl or such, because IMHO it is a different use (the new style would be allowed only if libfaketime already running). But this is not technical forcing of course. Probably all just a matter of taste.

[wolfcw]

This is one of the issues we hope to fix by switching to autoconf/automake (#178 and others). Autoconf sounds great! Is it in a branch? I don't understand the ticket, there is something about PR but then some revert?

@manchicken is working on autoconf integration, yes, and also has a Travis CI set up for his branch.

The overall style, so far, was to not let intercepted functions fail if libfaketime can continue despite such internal problems. fprintf to stderr is used in several cases to inform the user about such troubles which may result in deviating from the likely intended result.

I added that:

c2e45aa hack for #239: settime reports error writing to FAKETIME_TIMESTAMP_FILE`

I tried to align to the style and README.developer, but I'm afraid the style already is mixed. Just tell me how you want it, I'll reformat to whatever is considered most beautiful :)

I implemented a pragmatic version, what do you think:

$ chmod 0 timestamp_file
$ LD_PRELOAD=src/libfaketime.so.1 FAKETIME_TIMESTAMP_FILE=$(pwd)/timestamp_file /bin/bash -c 'date -s "1999-01-01 01:00:00" ; date'
libfaketime: In clock_settime(), failed to to open file while updating FAKETIME_TIMESTAMP_FILE (`/home/sdettmer/work/faketime/libfaketime/timestamp_file'): Permission denied

Please just tell if you like the message being changed.

Thank you, style and message are fine. Nice! :-)

Indeed, the usual style would be to introduce another envvar for "do write to FAKETIME_TIMESTAMP_FILE or not?". It's fine to force users to use FAKETIME_TIMESTAMP_FILE in such a case, but getting this file overwritten should explicitly be indicated by the users. It would also be fine to introduce backwards-compatible changes to the envvar's syntax; for example, so far it only contains a filename, but if you optionally add a prefix like "+" to the filename, it's OK to overwrite it.

OK, I think I can implement either option easily, but please tell me which one do you prefer. For the first please choose a variable name (for me as newbie its hard to find the right style I guess). If using the prefix "+" (or tell another one, as you like) of course I also need to change the place where it is read. Actually this other place already has a small minor bug, namely in case no FAKETIME_TIMESTAMP_FILE it tries to open a file "(null"):

I'd probably go for something like FAKETIME_UPDATE_TIMESTAMP_FILE=1, but you name it. :-) It could also be done in both variants, but we can add the other one later as well (and fix the problems you spotted there!).

The wrapper, called faketime, is just a simple and more comfortable way to use libfaketime than setting all the environment variables manually.

OK, thanks, I see. A launcher. I think it converts command line options to environment variables, so I would use a shell script instead, could be simpler. It also zero-inits the SHM (in the zero init, two fields are -1, which IMHO is not zero :)). From stomach feeling this is a bit odd to have this here, it this really needed?

Then I would not use the launcher, but make an own little tool, faketimectrl or such, because IMHO it is a different use (the new style would be allowed only if libfaketime already running). But this is not technical forcing of course. Probably all just a matter of taste.

Well, the wrapper, or launcher as you call it, used to be a shell script. Then @rbalint added all the shm stuff and the wrapper turned into a binary.

One reason to integrate new functionality into the faketime wrapper/launcher is that some package maintainers / distributions are not too fond about programs shipping with many executables. However, if that makes it easier to get it started, I'm nevertheless very happy with a separate program (faketimectrl) to see how the stuff works out, and would look into integration with the wrapper later.

[manchicken]

@wolfcw I’m sorry, I can’t remember for the life of me what is still outstanding on the autotools stuff. I thought we had finished all of that.

[sdettmer]

@manchicken how can I play with it? Is a rebase needed? @wolfcw Is merging auto* considered? Sounds veeeervy impacting?

[sdettmer]

About my patch, so I add check for FAKETIME_UPDATE_TIMESTAMP_FILE=1, remove all "Hack" stuff, rewrite a single commit and create a PR, is this the way to go? Anything else? Documentation probably at least, I think I update README, right?

[manchicken]

Yeah, just rebase I believe. I’m not sure if @wolfcw merged this into master or another branch.

~ Michael D. Stemle, Jr.

On Apr 8, 2020, at 15:40, Steffen Dettmer notifications@github.com wrote:

 @manchicken how can I play with it? Is a rebase needed? @wolfcw Is merging auto* considered? Sounds veeeervy impacting?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[wolfcw]

For the new FAKETIME_UPDATE_TIMESTAMP_FILE: Yes, a single-commit PR would be great, and I'd appreciate if you also update the README accordingly (I'd do that if you don't have the time, but since you invented it, you're the best one to describe it :-)).

@manchicken's automake is meanwhile available as automake branch here, thanks and sorry for the delay. Some aspects here are that the README needs more updates (e.g., how to pass the newly introduced flags; it also still refers to editing src/Makefile to change defaults, which probably is outdated), and I don't think it yet auto-detects platforms on which FORCE_MONOTONIC_FIX is required (at least it hangs with that on Travis CI for me). I've also changed line 14 of test/test.sh, as the [[ syntax did not work for sh on Linux for me; we probably need to do more testing on that but then it could be merged into master.

[sdettmer]

ok, I created that. Now the documentation is twice as much as the new code :-)

[wolfcw]

thank you, that went from an idea to a clean and fully documented PR very quickly. :-)