Linux FXServer newer artifacts unable to run via systemd

For all Linux server artifacts newer than 1141 (versions 1244-1387), I am unable to get it to run via systemd. I’m seeing this on Ubuntu 16.04, Ubuntu 18.04, and Amazon Linux (which is the only distributions I’ve tried). Older artifact versions do work fine. I can easily reproduce this on a vanilla FXServer with the default resources…no custom resources.

Here’s my systemd service script:

[Unit]
Description=FiveM Dev Server
After=network-online.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/fivem/dev
ExecStart=/home/ubuntu/fivem/start.sh
KillMode=control-group
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Here is the server log showing what happens when starting the server. You can see that it seems to successfully get through the start-up process, but then Mono immediately explodes.

Authenticating server license key...
Server license key authentication succeeded. Welcome!
/proc/self/maps:
400e6000-400f6000 rwxp 00000000 00:00 0
40723000-407c3000 rwxp 00000000 00:00 0
4082d000-408fd000 rwxp 00000000 00:00 0
104b4ded8000-104b4dee0000 rw-p 00000000 00:00 0
11ef75c80000-11ef75d00000 rw-p 00000000 00:00 0
1cf720280000-1cf720283000 rw-p 00000000 00:00 0
1cf720283000-1cf720300000 r--p 00000000 00:00 0
228652fe2000-228653000000 ---p 00000000 00:00 0
228653000000-228653003000 rw-p 00000000 00:00 0
228653003000-228653004000 ---p 00000000 00:00 0
228653004000-22865307f000 r-xp 00000000 00:00 0
22865307f000-22865afe2000 ---p 00000000 00:00 0
2c4c15080000-2c4c15100000 rw-p 00000000 00:00 0
2d35fbd00000-2d35fbd03000 rw-p 00000000 00:00 0
2d3b8be00000-2d3b8be80000 rw-p 00000000 00:00 0
337ee9080000-337ee90af000 rw-p 00000000 00:00 0
7f20b0af4000-7f20b0af6000 ---p 00000000 00:00 0
7f20b0af6000-7f20b0bf8000 rw-p 00000000 00:00 0
7f20b0bf8000-7f20b0bfa000 ---p 00000000 00:00 0
7f20b0bfa000-7f20b0cfc000 rw-p 00000000 00:00 0
7f20b0cfc000-7f20b0cfe000 ---p 00000000 00:00 0
7f20b0cfe000-7f20b0cff000 rw-p 00000000 00:00 0
7f20b0cff000-7f20b0d07000 ---p 00000000 00:00 0
7f20b0d07000-7f20b1000000 rw-p 00000000 00:00 0
7f20b10b2000-7f20b10f3000 rw-p 00000000 00:00 0
Memory around native instruction pointer (0x7f20bc63c4e4):
0x7f20bc63c4d4  48 8b 3c 25 28 00 00 00 48 89 7c 24 50 48 8b 38  H.<%(...H.|$PH.8
0x7f20bc63c4e4  48 8b 5f f0 48 8b 7f f8 48 89 14 24 48 89 44 24  H._.H...H..$H.D$
0x7f20bc63c4f4  08 48 89 74 24 10 48 89 4c 24 18 0f 57 c0 0f 11  .H.t$.H.L$..W...
0x7f20bc63c504  44 24 3f 0f 11 44 24 30 48 01 c3 0f 11 44 24 20  D$?..D$0H....D$
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

In this state, the run.sh process launched by systemd is running at max CPU and obviously the FXServer doesn’t work.

Executing the server in the exact same way directly in the shell instead (/bin/bash /home/ubuntu/fivem/fx/1387/run.sh +exec /home/ubuntu/fivem/dev/server.cfg) allows the server to run properly, interestingly. But I wouldn’t call that a solution.

This seems like a bug in the Linux build, perhaps? Maybe it’s a compatibility issue or a breaking change that I haven’t accounted for. I’m not certain what may have changed in the Linux build after version 1141 that could cause this. Anybody else seeing this problem? Or not seeing this problem?

Thanks!

3 Likes

Ran into the same problem; using the latest artifacts as of today on a fresh Ubuntu 19.04 system.

I found another workaround though: running the server inside a tmux session. You can still have it managed by systemd:

[Unit]
Description=FiveM Server

[Service]
WorkingDirectory=/home/user/server-data
User=user
Type=forking

ExecStart=/usr/bin/tmux new-session -s fivem -d '/bin/bash /home/user/server/run.sh +exec server.cfg'

[Install]
WantedBy=multi-user.target

So far that seems to be working fine for me. Starts up with the server, no SIGSEGVs, etc. Plus it has the benefit of being able to SSH to the server later and attach to the tmux session if you need to give the server commands directly.

I also noticed that sending CTRL+C to the server causes a SIGSEGV. Don’t know if that’s related, but maybe that info is helpful to the developers.

Interesting. When you use tmux does the output from the server log make it back to systemd for logging?

I’ve recently started testing using supervisord and this has so far been successful as well.