process lifetime issues

[ltfetch]

faketime is a great tool! I've been using it for a few things, but there's one problem that keeps biting me: after the faketime process ends, it can leave env vars like LD_PRELOAD and the faketime date set in child processes' environment, and those processes will fail to create children because said children always fail in calls to sem_open (because the faketime process has terminated).

An example:

$ faketime '' sh
sh-4.3$ xterm &
sh-4.3$ exit

then try to run a command in the xterm. It will fail with sem_open: No such file or directory.

It's not hard to manually avoid this problem when using faketime in the shell, but it becomes an issue when using faketime on complex shell scripts that run commands in the background, and it's not feasible to rewrite all of those.

[rbalint]

Hi, what you observe is the intentional design. Please wait for all
background processes before exiting faketime.
Otherwise the processes should crash to let failures in faking timestamps.

[ltfetch]

"sem_open: No such file or directory" is /not/ an error message which makes it clear to users that they have misused the tool and are afoul of a conscious design decision. The man page for faketime says that "While timestamps and time offsets will work for child processes, speeding the clock up or slowing it down might not work for child processes spawned by the executed program as expected..."; this led me to believe that faketime was intended to gracefully handle simple, common patterns of process hierarchies.

Would you accept a patch that has faketime wait for its transitive children to exit before it terminates? Or do you have reason to believe this isn't (portably) feasible with POSIX job-control faculties? If the latter is the case, would you be amenable to a cgroup-based solution that works on Linux?

As I stated, it's often not within my control whether all background processes have terminated when faketime exits; many programs and scripts spawn children which continue running after the parent has ended.

Thanks for your timely response. :)

[rbalint]

OK, let's try to handle forked processes more gracefully. At least a better error message would be useful, I agree.

I think the man page refers to the old behavior where forked processes started the clock where it started in the parent process, but I agree that it is not clear and instead of removing a non-existing "feature" from the documentation I'm open for implementing it or providing a guide.:-)

Patches are welcome, but I'm wondering if it would be cleaner to use a helper command instead which waits for all subprocesses to finish and run your command like this: "faketime waitall foo".