[14.22] Linux: headless server running as service fails to write to saves folder

[RaumSchnee]

While testing my server setup for stability, I came across a problem where the auto-save feature of the headless server. The error it is throwing is that is cannot open the auto-save file for writing. I am running it as a service on a CentOS 7 server, and the Factorio directory has read/write enabled for any user. It is a vanilla map that a friend and I played via client hosting before. The map loads and is completely playable and stable, right up until the auto-save.

Error Log and Save File will be attached below.

One thought I had is that because I have just started this server, the auto-save file doesn't exist yet, although I would think that the save function in the server would be able to create a new file, given that the directory it is trying to write to has write permission.

Any help or ideas would be welcome.
Thanks in advance
-Raum Schnee

[Loewchen]

Pretty sure you ran out of RAM when trying to save.

[RaumSchnee]

-Loewchen
That would be a possibility I am willing to accept, however, Factorio has access to over a gig and a half of ram for a headless system. And while a am aware that low ram can cause problems, why is the save system needing ram to save? wouldn't that need hard drive space? and why can the server host and run the game if it is a ram issue?

If that is the case, I am honestly confused about why.

[Loewchen]

why is the save system needing ram to save? wouldn't that need hard drive space?

Every process needs RAM, saving is an additional one and therefore needs additional RAM especially for compression.

And why can the server host and run the game if it is a ram issue?

No idea what you mean by that, hosting is the same as running the game, you only have no video output with a headless server.
Lets just wait for a dev to take a look.

[quyxkh]

192.168 is a LAN address, are you sure you're not trying to run the client with write-data set to `/opt/factorio` too? They can't share that.

[Loewchen]

Is it simply this one: 43733?

[RaumSchnee]

why is the save system needing ram to save? wouldn't that need hard drive space?

Every process needs RAM, saving is an additional one and therefore needs additional RAM especially for compression.

And why can the server host and run the game if it is a ram issue?

No idea what you mean by that, hosting is the same as running the game, you only have no video output with a headless server.
Lets just wait for a dev to take a look.

I slightly misunderstood you comment, sorry. I know that you need to be able to execute the commands to save and such, which (from what I could find online) in this case is only about 20 MB.

I also misspoke when I said host and run the game. (Don't use a forum when tired. )

192.168 is a LAN address, are you sure you're not trying to run the client with write-data set to `/opt/factorio` too? They can't share that.

It is indeed a LAN address. I have the server tower at my house. I would like to be able to connect via the multiplayer menu, but it has issues because it's a local server.

Is it simply this one: 43733?

My issue is a separate one. If I have the impression that I am running the game and server on the same tower, I didn't mean to. I run the full game on my windows tower, and run the headless on the Linux tower. The headless has 1.8 GB available RAM, and online I found that 2 would be enough.

[posila]

Not sure about running out of memory. Crash due to running out of memory is almost exclusive to 32bit systems, because the process will run out of address space and can't continue its normal execution. On 64bit there is plenty of address space and OS can swap memory to disk, so unless swap is disabled or disk is full it shouldn't crash, it would just become extremely slow.

But the log contains this:

Code: Select all

 423.281 Warning WriteFileGuard.cpp:25: Writing /opt/factorio/saves/_autosave1.zip failed; previous version (if any) should still be available
 423.281 Error ParallelScenarioSaver.cpp:82: Saving scenario failed: Opening package /opt/factorio/saves/_autosave1.tmp.zip for writing failed
 423.287 Error Util.cpp:57: Attempting to create notice box in headless mode. Message: 'Opening package /opt/factorio/saves/_autosave1.tmp.zip for writing failed'
 423.713 Info ServerMultiplayerManager.cpp:115: Disconnecting multiplayer connection.

It seems like Factorio could not save to its saves folder and terminated itself (in order to not lose more progress when unable to save)

[RaumSchnee]

Thanks for taking a look at this posila. I'm also glad I can still read an error report. I did see that in the log the first time round, and I tried to fix it by running. Chmod 755 on the factorio directory. It didn't fix it,and I tried rebooting the whole server to see if it just didn't update the permissions. I couldn't think of anything on my end of things that could cause the error, so I posted it on the forum.

I did some thinking while at work these last few days, and I wondered if the autosave files need to exist before it tries to save. I also wonder if doing a manual save from the server works, or if it has the same issue as the autosave. I'll run some tests tomorrow, and put up the results here.

[posila]

Autosave file doesn't need to exist, in fact it saves to _autosave1.tmp.zip and if that succeedes it deletes the old autosave and renames new one to remove tmp.

Interestingly enough it managed to save to /opt/factorio/temp/mp-save-0.zip when someone was connecting to the server.

I am not Linux user, but I don't think chmod 755 is "read/write enabled for any user" ... I might be wrong though.

I am moving this thread to Technila help for time being as more experienced linux users might be more likely to help you there.

[quyxkh]

Interestingly enough it managed to save to /opt/factorio/temp/mp-save-0.zip when someone was connecting to the server.

And this is why suspect there's a client (or maybe a second server?) running.

Since this is supposed to be a headless server, `pgrep factorio` should show exactly one process, that's probably worth checking.

[RaumSchnee]

Now that I have had a chance to get home and fix this, i have found the issue! Posila was right, 755 wasn't good enough. i upped it to 767, and it works great.

Just goes to show, check everything you have control over before calling it a bug.

Thnaks for all the help!