wolfcw / libfaketime

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

sem_open failed and recreation attempts failed: No such file or directory #377

Closed wanghaiqing2015 closed 1 year ago

wanghaiqing2015 commented 2 years ago

sem_open failed and recreation attempts failed: No such file or directory

this is error infomation

[root@license-server ~]# export LD_PRELOAD="/root/libfaketime/src/libfaketime.so.1" [root@license-server ~]# export FAKETIME="2021-12-23 11:16:00" [root@license-server ~]# [root@license-server ~]# [root@license-server ~]# aether libfaketime: In ft_shm_init(), sem_open failed and recreation attempts failed: No such file or directory libfaketime: sem_name was /faketime_sem_28932, created locally: false libfaketime: In ft_shm_init(), sem_open failed and recreation attempts failed: No such file or directory libfaketime: sem_name was /faketime_sem_28932, created locally: false libfaketime: In ft_shm_init(), sem_open failed and recreation attempts failed: No such file or directory libfaketime: sem_name was /faketime_sem_28932, created locally: false /data/linux26-x86_64 x86_64 /data/platform/linux26-x86_64/bin/aether: error while loading shared libraries: liboaPlugIn.so: cannot open shared object file: No such file or dir ectory

wanghaiqing2015 commented 2 years ago

the latest version

wolfcw commented 2 years ago

It seems like, for whatever reason, libfaketime is loaded within a libfaketimed session, but with different privileges.

Please make sure to delete stale faketime* files in /dev/shm, and that there is no environment variable FAKETIME_SHARED set.

If you run into the same problem again, check for the semaphore file name (last time: faketime_sem_28932), in which 28932 is the PID of the process that failed to pass its libfaketime setting down to child processes. If you find out which process that is, it might help for debugging.

zsolt-anyvan commented 2 years ago

The same issue is appearing for me when I try to use libfaketime on jwilder/nginx-proxy based docker container. I'm also lasing the latest master of your repository.

In the Dockerfile I tried to add these configurations

ENV LD_PRELOAD=/faketime.so \
    FAKETIME_DONT_FAKE_MONOTONIC=1 \
    FAKETIME="2022-01-01 00:00:00" \
    FAKETIME_DONT_RESET=1 \
    FAKETIME_NO_CACHE=1
nginx.1     | libfaketime: In ft_shm_init(), sem_open failed: No such file or directory
nginx.1     | libfaketime: sem_name was /faketime_sem_1, created locally: false
nginx.1     | libfaketime: parsed from env: /faketime_sem_1 /faketime_shm_1
wolfcw commented 2 years ago

For the background: libfaketime enables the synchronisation of faketime settings between parent and child processes via shared memory. For this purpose, a shared memory segment and a semaphore file are placed in /dev/shm (on Linux), with the process id (PID) of the parent process (1 in your case) in its filename. The existence of these files is passed on to child processes using FAKETIME_SHARED as environment variable. When a (child) process finds this environment variable set, it tries to read it, so it can access the synchronisation settings from shared memory.

In your cases, this access to the semaphore file fails, and the official error code is "No such file or directory", which may not be too useful.

Failing to access these files can have a number of reasons. If it was created by a parent process, maybe the parent process already terminated and cleaned it up. Maybe child process privileges do not allow access to shared memory. Maybe the child process sees a completely different /dev/shm than the parent process due to container specifics. It's hard to tell.

The basic solution idea is to first make sure that access to shared memory is granted, as there could be security-related restrictions in place. Then, LD-preload libfaketime as late as possible (just for your application, not for the whole container or all processes in it). If the latter is not possible for whatever reason, make sure that FAKETIME_SHARED is not set when nginx is started.

ttimasdf commented 1 year ago

LD-preload libfaketime as late as possible (just for your application, not for the whole container or all processes in it)

This fixed my java application. 👍