wolfcw / libfaketime

libfaketime modifies the system time for a single application
https://github.com/wolfcw/libfaketime
GNU General Public License v2.0
2.62k stars 319 forks source link

killing (SIGTERM) faketime process does not terminate "faketime-d" child process #428

Open ametzler opened 1 year ago

ametzler commented 1 year ago

Hello,

faketime cannot be used like this ...

# start server process
faketime '2022-12-13 10:00:00' server &
PID=$!
# ... testing ...
kill $PID

... since $PID contains the process ID of the faketime executable instead of the real one and killing faketime does not kill the child.

cu Andreas [EDIT: Could you use exec() instead of fork()?]

wolfcw commented 1 year ago

An alternative is to set the LD_PRELOAD and FAKETIME environment variables directly when launching that server process into the background instead of using the faketime wrapper.

There are different ideas for extensions of the faketime wrapper's functionality, which partially would require it to keep running as parent process, so replacing itself with the started program on this side of a fork might not be the ideal option (although it would be currently viable, you're right).

ametzler commented 1 year ago

wolcw wrore:

An alternative is to set the LD_PRELOAD and FAKETIME environment variables directly when launching that server process into the background instead of using the faketime wrapper.

That is would complicate the usecase I am looking at (GnuTLS) quite a bit. With the faketime excutable one simply tries to run it. OTOH the path libfaketime is installed in differs a lot between machines and distributions. (e.g. It is /usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 on my local installation. On Fedora we would see /usr/lib64/faketime/libfaketime.so.1 or /usr/lib/faketime/libfaketime.so.1)

dkg commented 11 months ago

The simplest approach would be to just exec, not to fork at all, right?

Looking at src/faketime.c, it looks like the only reason that the faketime wrapper process stays open is to hold open the semaphore and shared memory segment until all children die. And it measures whether all children have died by reading from the keepalive pipe FD, which is a plausible (but not perfect) symbol, assuming processes don't go around closing or writing to inherited file descriptors that they didn't already know about.

But does this require the daemonized faketime process to be the parent process instead of the child process?

And: presumably the semaphore and shared memory segment are used for coordination between descendent processes, right? And why wouldn't the semaphore and shared memory segment get cleaned up in the first place when those processes terminate?

Sorry if these are unsophisticated questions, or are based on some misunderstanding on my part. it'd be helpful to have explicit answers anyway, if we want to brainstorm any possible fix.

messa commented 3 months ago

Would be nice if faketime wrapper (the parent process) could pass received signals (SIGTERM...) to the child process.