[GH-ISSUE #4680] [Bug]: Unable to start multiple instances of Core Keeper due to xvfb-run #2908

New issue

Open

opened 2026-02-27 03:06:13 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 03:06:13 +03:00

Owner

Originally created by @Crimson-Decoded on GitHub (Oct 1, 2024).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4680

User story

As a server admin, I want to be able to start multiple instances of Core Keeper server

Game

Core Keeper

Linux distro

Ubuntu 22.04, Other

Command

command: start, command: monitor

Further information

Note, this may not affect only core keeper, but could potentially affect ANY game server that uses xvfb-run

xvfb-run, which is used as the preexecutable for Core Keeper server, has a limitation in that running just the command alone will attempt to create and use x server number 99. However only one xvfb-run can only use one x server, therefore when attempting to start a second instance of Core Keeper, it fails to start citing xvfb-run: error: Xvfb failed to start

xvfb-run -a should be the bare minimum, as this allows xvfb-run to auto select an x server, from 99 to 599, starting at 99, and incrementing until it finds an open x server.
xvfb-run -n ### lets you specify an x server number, but hard coding this is effectively the same as not selecting any x server.
xvfb-run -a -n ### is the combination of both, where it selects a random x server, starting at ###, incrementing until it finds an open x server

However, this is also partially flawed, as two xvfb-run -a running simultaneously (such as with a systemd unit on boot) will not account for each other, and may end up selecting the same x server number, resulting in one still failing.

I don't know if there's a truly fool-proof way to mitigate this. using xvfb-run -a -n $(shuf -i100-599 -n1) (or whatever random range method preferred) should mostly mitigate this, however there is still the off chance that both end up generating the same random number due to the relatively small scope (compared to the normal range for random numbers), and therefore can still collide when starting simultaneously.
Alternatively, this may be possible by fuzzing the start time of core keeper by a random number of seconds, say... somewhere between 5 and 45s. Probably don't want this too large, because then people that use monitor cron jobs might have issues. But again, due to the small scope, duplicate randoms are possible, even if unlikely.

In theory, standard PRNG uses the PID and nanosecond time to generate a number, so even two starting parallel at the same nanosecond time should be different values, however that's assuming the standard range that the PRNG algorithm uses. When shortening the range, regardless of method used, the likelihood of two simultaneous randoms being the same becomes more likely.

I don't know if there's a "best" way to prevent xvfb-run x server issues, or a way to guarantee no overlap other than selecting static server numbers per instance, but that would need to be done by the user. That is an option, though.

Perhaps just making a variable in the Predefined Parameters in the config like:

# Change this to a unique number between 99 and 599 for each instance of Core Keeper
xservnum="199"

Then change the preexecutable to
xvfb-run -a -n ${xservnum}

Relevant log output

No response

Steps to reproduce

Create and start one Core Keeper server
Create and attempt to start another Core Keeper server
Review console logs to see xvfb-run: error: Xvfb failed to start

Originally created by @Crimson-Decoded on GitHub (Oct 1, 2024). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4680 ### User story As a server admin, I want to be able to start multiple instances of Core Keeper server ### Game Core Keeper ### Linux distro Ubuntu 22.04, Other ### Command command: start, command: monitor ### Further information Note, this may not affect only core keeper, but could potentially affect ANY game server that uses xvfb-run xvfb-run, which is used as the preexecutable for Core Keeper server, has a limitation in that running just the command alone will attempt to create and use x server number 99. However only one xvfb-run can only use one x server, therefore when attempting to start a second instance of Core Keeper, it fails to start citing `xvfb-run: error: Xvfb failed to start` `xvfb-run -a` should be the bare minimum, as this allows xvfb-run to auto select an x server, from 99 to 599, starting at 99, and incrementing until it finds an open x server. `xvfb-run -n ###` lets you specify an x server number, but hard coding this is effectively the same as not selecting any x server. `xvfb-run -a -n ###` is the combination of both, where it selects a random x server, starting at ###, incrementing until it finds an open x server However, this is also partially flawed, as two `xvfb-run -a` running simultaneously (such as with a systemd unit on boot) will not account for each other, and may end up selecting the same x server number, resulting in one still failing. I don't know if there's a truly fool-proof way to mitigate this. using `xvfb-run -a -n $(shuf -i100-599 -n1)` (or whatever random range method preferred) should mostly mitigate this, however there is still the off chance that both end up generating the same random number due to the relatively small scope (compared to the normal range for random numbers), and therefore can still collide when starting simultaneously. Alternatively, this may be possible by fuzzing the start time of core keeper by a random number of seconds, say... somewhere between 5 and 45s. Probably don't want this too large, because then people that use monitor cron jobs might have issues. But again, due to the small scope, duplicate randoms are possible, even if unlikely. In theory, standard PRNG uses the PID and nanosecond time to generate a number, so even two starting parallel at the same nanosecond time should be different values, however that's assuming the standard range that the PRNG algorithm uses. When shortening the range, regardless of method used, the likelihood of two simultaneous randoms being the same becomes more likely. I don't know if there's a "best" way to prevent xvfb-run x server issues, or a way to guarantee no overlap other than selecting static server numbers per instance, but that would need to be done by the user. That is an option, though. Perhaps just making a variable in the Predefined Parameters in the config like: ``` # Change this to a unique number between 99 and 599 for each instance of Core Keeper xservnum="199" ``` Then change the preexecutable to `xvfb-run -a -n ${xservnum}` ### Relevant log output _No response_ ### Steps to reproduce 1. Create and start one Core Keeper server 2. Create and attempt to start another Core Keeper server 3. Review console logs to see `xvfb-run: error: Xvfb failed to start`

kerem added the

labels

2026-02-27 03:06:13 +03:00

kerem commented

2026-02-27 03:06:14 +03:00

Author

Owner

@Crimson-Decoded commented on GitHub (Oct 1, 2024):

I myself didn't have the issue, but helped a user solve it here
https://discord.com/channels/127498813903601664/1290346537104314472/1290346537104314472

@Crimson-Decoded commented on GitHub (Oct 1, 2024): I myself didn't have the issue, but helped a user solve it here https://discord.com/channels/127498813903601664/1290346537104314472/1290346537104314472

kerem referenced this issue

2026-02-27 03:55:59 +03:00

[PR #2908] [CLOSED] feat(new server): openttd #3834