[unstable 1.1.2701] "Unable to open log file, exiting" on multi-user Linux

[Jayschwa]

The Linux shell scripts for launching the game (e.g. start_RimWorld.sh) pass `-logfile /tmp/rimworld_log` to the game executable. The first user on the machine to launch the game becomes the owner of the /tmp/rimworld_log file. If another user on the machine attempts to start the game, it fails with the following error: "Unable to open log file, exiting". This is because the second user is not authorized to open a file owned by the first user.

Affected users can workaround the problem by removing any existing /tmp/rimworld_log, which may require super user permissions. Non super users can try rebooting the machine, which clears the /tmp directory on some Linux distributions.

Suggested solution: The shell scripts should be updated to place the log file somewhere in the user's $HOME directory.

[Canute]

I don't have expierence with linux, but reffering to the sticky the logfile should be created for each user on different places.

/home/<YourUserName>/.config/unity3d/Ludeon Studios/RimWorld/Player.log

did you look at your user folder or at the one from someone else ?

[Jayschwa]

The problem is for a different log file, not the one in .config/unity3d/Ludeon Studios/RimWorld/Player.log.

[Canute]

Or maybe you use `-logfile /home/<YourUserName>/rimworld_log` so every use write the log at his own userfolder.

[Jayschwa]

This issue is still present in build 1.1.2647. I have updated the subject title.

[LWM]

Running the game from Steam, the logfile is automatically set to /tmp/rimworld_log (line 24 of start_Rimworld.sh).

Perhaps it would be better to:

Code Select Expand


LOG="-logfile /tmp/rimworld_log_$UID"
# or perhaps
LOG="-logfile /tmp/rimworld_$UID.log"


This would allow Steam (and non-steam players) to correctly start the game.

But yes, this is a problem, and unless the player is knowledgeable, is very difficult to track down - especially for a Steam user.  Please update the start scripts.

Thanks!

[Jayschwa]

This bug is still present in the 1.1.2701 unstable build. I updated the title to reflect.

[Nowhere]

Should be fixed in a next unstable build (1.1.2706 or later), thanks for reporting!