[Bug] FXServer (GTA V Enhanced, early-access b90) hangs on startup inside Docker

[error-fr]

Summary

Summary

The GTA V Enhanced (early-access) Linux server artifact hangs during startup when run
inside a Docker container. The process freezes at 0% CPU right after
Server data will be saved in ..., before txAdmin prints its "All ready!" panel — so the
txAdmin web server (port 40120) never binds and the server is unusable.

The exact same artifact, on the same host, run on bare metal, starts perfectly (prints
the txAdmin setup URL + PIN and binds port 40120). The hang is Docker-specific.

Version / build

• Server: txAdmin v9.0.0-beta-f664af9d / b90-ea ("custom branch: early-access")
• Artifact: cfx-server_linux_x64.tar.xz
  URL: https://downloads.cfx-services.net/prod/019f8155-958f-7748-af5a-e80e9b48966c/cfx-server_linux_x64.tar.xz
• Platform: GTA V Enhanced (Early Access)

Issue type

Server

Repro rate

Always

Server build version

latest

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Docker

OS version / distribution

Debian, kernel 6.12.74+deb13+1-amd64, x86_64

CPU

AMD EPYC 4244P - 6c/12t - 3.8 GHz/5.1 GHz

RAM

64 Go 5200 MHz

Using txAdmin?

Yes

Hosting provider

Cloud provider (AWS, GCP, Azure, etc.)

Machine type

Dedicated

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

FROM alpine:latest AS base
ARG url="https://downloads.cfx-services.net/prod/019f8155-958f-7748-af5a-e80e9b48966c/cfx-server_linux_x64.tar.xz"
RUN apk -U upgrade --no-cache && apk -U add --no-cache curl && \
    mkdir -p /opt/cfx && \
    curl -fSL --retry 3 "$url" | tar xJ -C /opt/cfx

FROM scratch
COPY --from=base /opt/cfx/ /opt/cfx/
EXPOSE 30120/tcp 30120/udp 40120
WORKDIR /opt/cfx/
ENTRYPOINT ["/opt/cfx/alpine/lib/ld-musl-x86_64.so.1", \
    "--library-path", "/opt/cfx/alpine/lib/:/opt/cfx/alpine/usr/lib/", "--", \
    "/opt/cfx/alpine/opt/cfx-server/cfx-server", \
    "+set", "citizen_dir", "/opt/cfx/alpine/opt/cfx-server/citizen/"]

Steps to Reproduce

Build the image from the Enhanced (early-access) Linux artifact and run it. Dockerfile used.

1. Build
   docker build -t fxtest .

2. Run
   docker run --rm -p 40120:40120 fxtest

Expected Behavior

The server should complete startup inside Docker the same way it does on bare metal:
txAdmin finishes booting, prints its setup panel and PIN, and binds the web port (40120).

Confirmed on bare metal (same artifact, same host, via the bundled run.sh)

Actual Behavior

Inside a Docker container, startup freezes. The logs stop after 4 lines and never advance;
the process sits at 0% CPU indefinitely:

[info] txAdmin says: *
[tx] You are running a custom branch of FXServer: early-access.
[tx] Starting txAdmin v9.0.0-beta-f664af9d/b90-ea/Lin...
[tx] Server data will be saved in  /opt/cfx/txData/default

• The txAdmin "All ready!" panel is never printed.
• Port 40120 never binds — HTTP requests get connection reset (nothing listening inside the container).
• /proc/1/task/1/wchan shows the main thread blocked on pipe_read (State: S sleeping,
  8 threads; worker threads in futex_wait, event loop in epoll_wait).
• strace -f shows only thread-creating clone() calls (CLONE_THREAD) succeeding — no
  clone3, and no process fork/execve. It hangs before spawning the FXServer child process.

The freeze happens at the exact point where, on bare metal, txAdmin prints the "All ready!" panel.

Evidence

No response

Additional Context

Virtual Machine on Proxmox (on the server details provided upper)

Debug and written with Claude AI.

[tabarra]

Can you please run it with the two following env vars and post the entire terminal output here?

TXDEV_VERBOSE=true TXDEV_DEBUG_RUNTIME=true ./run.sh

[stelianclaudiu92-commits]

TXDEV_VERBOSE=true TXDEV_DEBUG_RUNTIME=true ./run.sh 2>&1 | tee /tmp/fivem_log.txt
[2026-07-22 02:24:00.480] [info] txAdmin says: *
======================= RUNTIME INIT =======================
{
process: {
argv: [
'/home/fivem/server-enhanced/alpine/lib/ld-musl-x86_64.so.1',
'/home/fivem/server-enhanced/alpine/opt/cfx-server/system_resources/txadmin/core/index.js',
'--runtime-branch early-access --runtime-version b92',
'+set',
'citizen_dir',
'/home/fivem/server-enhanced/alpine/opt/cfx-server/citizen/'
],
execArgv: [],
argv0: '/home/fivem/server-enhanced/alpine/opt/cfx-server/cfx-server',
cwd: '/home/fivem/server-enhanced'
},
NodeVersion: '26.3.0',
BunVersion: undefined,
__dirname: '/home/fivem/server-enhanced/alpine/opt/cfx-server/system_resources/txadmin/core',
'import.meta.dir': undefined
}

======================= RUNTIME INFO =======================
{
runtime: 'fxserver',
runtimeVersionTag: 'cfxs/92',
txaPath: '/home/fivem/server-enhanced/alpine/opt/cfx-server/system_resources/txadmin',
txaResourceName: 'txadmin',
fxsPath: '/home/fivem/server-enhanced/alpine/opt/cfx-server',
fxsBinaryPath: '/home/fivem/server-enhanced/alpine/opt/cfx-server/cfx-server',
fxsIsGen9: true,
fxsVersionInfo: {
valid: true,
branch: 'early-access',
build: 92,
raw: '--runtime-branch early-access --runtime-version b92'
}
}

[02:24:00][tx] You are running a custom branch of FXServer: early-access.
[02:24:00][tx] Starting txAdmin v9.0.0-beta-f664af9d/b92-ea/Lin...
[02:24:00][tx] Server data will be saved in /home/fivem/server-enhanced/txData/default
[02:24:00][tx:ConfigStore] Empty configuration file.

[yulz069]

If tabarras fix does not work. Try to add this in docker compose service:. This was my fix who worked for me
security_opt:
- seccomp:unconfined

[stelianclaudiu92-commits]

Reproduced this on bare metal (no Docker at all), and also just tested inside a container both with and without seccomp:unconfined — same hang in all four cases. Full details below, including a strace trace down to the exact syscall it's stuck in.

Environment (bare metal)

Rocky Linux 10.2, kernel 6.12.0-211.16.1.el10_2.0.1.x86_64
Confirmed non-containerized: systemd-detect-virt = none, no /.dockerenv, Seccomp: 0 in /proc/1/status and /proc/self/status
Artifact: cfx-server_linux_x64.tar.xz, GTAV Enhanced, early-access branch
runtime-branch early-access --runtime-version b92, txAdmin v9.0.0-beta-f664af9d/b92-ea, Node 26.3.0
TXDEV_VERBOSE=true TXDEV_DEBUG_RUNTIME=true ./run.sh output

Stops dead after [tx:ConfigStore] Empty configuration file. — no further output, port 40120 never binds, ~0% CPU. Note: the exact freeze point isn't fully deterministic — on some runs it froze one line earlier, right after [info] txAdmin says: *. Same hang, just different timing on a race.

Ruled out at the JS level — pulled ConfigStore/AdminStore source directly from the bundled system_resources/txadmin/core/index.js. Both are plain synchronous JS for a fresh profile, no blocking I/O/network/native calls. Not a txAdmin application-code bug.

strace -f -tt from process launch — normal V8/Node bootstrap for ~0.6s, then the main thread's last action:

rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1 RT_2], [], 8) = 0
read(4, 0x7ffd769771bf, 1) = ? ERESTARTSYS
fd 4 confirmed via /proc//fd as the read end of a self-owned pipe (fd 5 = write end, same process) — Node's self-pipe pattern for signal-to-main-thread wakeup. After that, every thread goes idle simultaneously, including the libuv event loop's epoll_pwait. Full stop, not a busy loop.

Re: seccomp:unconfined suggestion above — installed podman, rebuilt this issue's exact Dockerfile with our own copy of the artifact, tested both configs:

Default seccomp: same hang, froze at the same point, ~0.7% CPU avg over 2.5 min
--security-opt seccomp=unconfined: same hang, ~1.9% CPU avg over 50+ sec
Didn't help in our case — and given we're also seeing it on bare metal with zero seccomp restriction to begin with, doesn't look seccomp-related at all.

Possibly relevant — not universal: issue #34 has a full working boot log on a near-identical build (b90, same txAdmin version) on WSL2/Ubuntu 26.04 — resources loading, "All ready!" panel, players connecting. So this isn't broken everywhere. Given the hang centers on a self-pipe read + signal mask + kernel thread wakeup, my guess is it's kernel/distro-specific (RHEL/Rocky vs WSL2's patched kernel vs Debian) rather than a pure txAdmin bug — unverified guess though.

Summary: genuine deadlock in Node/libuv's self-pipe signal-handling path, reproducible on bare metal and in containers (with/without seccomp), apparently not universal across environments. Happy to provide the full raw strace log if useful.

Workaround: same as other reports — cfx-server +exec server.cfg directly (skipping embedded txAdmin) works fine.

[error-fr]

Update — workaround found: it's a seccomp issue.

First, thanks @tabarra for taking care of my issue.

I tried running my server with the two env vars but didn't get any more details, maybe I'm using them incorrectly?

The comment from @5LABS is very interesting and worked for me.

Running the container with the default Docker seccomp profile hangs at Server data will be saved in ... and never opens port 40120. Adding --security-opt seccomp=unconfined makes it boot normally. txAdmin reaches the "All ready!" panel and binds 40120 as expected.

So the Enhanced (early-access) server relies on a syscall that Docker's default seccomp profile blocks, which the Legacy build doesn't.

Disabling seccomp entirely is a heavy-handed workaround; ideally the server should avoid the blocked syscall, or you could document the specific one needed so users can allow just that in a custom profile.

[AtomicByte8]

I can also confirm that txAdmin (v9.0.0-beta-646aba9a/b96-ea) is unable to initialise when running in a docker container with seccomp enabled. This means that it is not currently feasible for Pterodactyl users to run FiveM for GTA V Enhanced since "Wings" (the daemon that manages servers on a Pterodactyl host) enforces this setting for created containers.

The result:

./run.sh
[2026-07-26 05:22:45.395] [info] txAdmin says: *

I tested with a derivative of Docker’s default seccomp profile where the fallback action was changed from SCMP_ACT_ERRNO to SCMP_ACT_LOG. txAdmin started normally and the audit log contains the syscalls which would have been blocked:

comm="node-MainThread" syscall=io_uring_setup
comm="DelayedTaskSche" syscall=io_uring_setup
comm="DelayedTaskSche" syscall=io_uring_enter
comm="txAdmin" syscall=io_uring_enter

On x86-64 these are:

io_uring_setup  = syscall 425
io_uring_enter  = syscall 426

Audit examples:

type=SECCOMP ... comm="node-MainThread" ... syscall=425 ... SYSCALL=io_uring_setup
type=SECCOMP ... comm="txAdmin" ... syscall=426 ... SYSCALL=io_uring_enter

If the integrated Node/txAdmin runtime could have a graceful fallback when io_uring returns EPERM that would enable compatibility with this type of environment.

[xBytez]

Also running into this on OKD/OpenShift. Additionally to Unconfined seccomp, I also had to enable io_uring on my worker node(s), I used tuned.openshift.io/v1 to change sysctl kernel.io_uring_disabled to 0.

[prikolium-cfx]

Could you try running it with ENV UV_USE_IO_URING = 0?

[stelianclaudiu92-commits]

You must use Ubuntu OS (for Linux). It does not work on Rocky Linux due to kernel issues.

[brainshead]

Any progress on this ? Even on cfx-server_linux_x64.tar.xz build 106 build

cfx-server +exec server.cfg directly (disabling TXadmin )works fine.

Please fix the Enhanced runtime so that it does not deadlock when running in standard Linux/container environments ?

[itsmeares]

I can run it perfectly on docker container with a simple compose

[brainshead]

Pterodactyl doesn't use compose (not the way you use it).
and its a standard compose ? Even people without docker has the same issue #50 (comment).
Can you show the compose file then ?
for pterodactyl it uses https://github.com/Ptero-Eggs/yolks/blob/main/oses/debian_bookworm/Dockerfile

[itsmeares]

Pterodactyl doesn't use compose (not the way you use it). and its a standard compose ? Even people without docker has the same issue #50 (comment). Can you show the compose file then ? for pterodactyl it uses https://github.com/Ptero-Eggs/yolks/blob/main/oses/debian_bookworm/Dockerfile

I just wanted to say that I can run it on compose so maybe that would be useful for you guys here

Here's my compose file I've been using it since b98 or an earlier version I think, no problem at all. It creates 4 containers on a single stack one of them is CFX Server itself.

https://github.com/itsmeares/cfx-server-docker/blob/main/compose.yaml

[brainshead]

not a standard docker i see you have the "fix" applied,In pterodactyl environment not really feasible .

[itsmeares]

not a standard docker i see you have the "fix" applied,In pterodactyl environment not really feasible .

oops, yep you are right about that.. I had that when I first made it so I forgot about that lol. I made it like 2 weeks ago and 2 weeks ago I didn't even know about the discussions here

SecurityOpt: []string{"no-new-privileges"}, they have this on Wings, didn't see anything like seccomp=unconfined so that's probably why and I couldn't see a custom seccomp profile setting when I searched. I haven't used Wings so I can't really say something about that.

I tried a new compose with and without seccomp options, the one without failed to run and the one that had override that allows io_uring_setup and io_uring_enter ran perfectly

so you're right that my original compose already had "fix", it is reproducible on plain docker, Ptero/Wings just makes it harder to apply fix because its normal container creation path doesn't provide the same custom seccomp override. However I can tell it's not a Pterodactyl problem, definitely something with CFX itself.

My bad 😬

[brainshead]

no probs , was just checking what worked on your side and i checked the compose file ;).

#50 (comment) already mentioned a possible fix ?
but need to wait if they want to support docker without disabling security layer features of docker.

wings is like shell around docker (Wings — The newer service written in Go that interfaces with Docker and the Panel to provide secure access for controlling servers via the Panel)