Jump to content
  • 0

Linux Dedicated Server as service issue


BeEatNU

Question

Following the steps for running a dedicated server on Linux , I was able to get this working prior before the massive hardware failure I had but now I run into an issue where creating the service where the OS says zomboid.control (no such file) so it doesn't exist. 
How can I produce this file? I didn't have this issue before but any help is appreciated. 

 

91O23N2.png

Link to comment
Share on other sites

10 answers to this question

Recommended Posts

Unfortunately this doesn't seem to resemble the dedicated server package that is provided through Steam. 

 

So, I don't actually know what zombie.control is, how it's called, or why. 

 

Just in case: we don't make Docker images or other forms of containers for the game. They often change the structure of the files and how the files interact with one another, which makes it all rather unpredictable.

Link to comment
Share on other sites

1 hour ago, BeEatNU said:

Thanks for the reply @EnigmaGrey 
I was using the directions here, https://pzwiki.net/wiki/Dedicated_Server#Through_SteamCMD

 

I thought this was from you guys, do you have any methods or how to's on running a dedicated via linux?

Hi BeEatNU, I am actually the one who modified the wiki to use "zomboid.control", it's necessary to have this file to run the server as a daemon due to the lack of SIGTERM handling ( a bug I have filed), as your server won't save correctly (on exit) if you don't (unless you use a workaround like rconsole). Will you post a picture of the "zomboid.socket" file you have made? And what linux distro are you running?

 

Edit:

Please make sure that "pzuser" owns /opt/pzserver with chown pzuser: /opt/pzserver

 

Also please send a picture of the zomboid.service file aswell.

 

I would also like to know the output of "file /bin/sh"

 

Link to comment
Share on other sites

2 hours ago, Tripodzomboid said:

Hi BeEatNU, I am actually the one who modified the wiki to use "zomboid.control", it's necessary to have this file to run the server as a daemon due to the lack of SIGTERM handling ( a bug I have filed), as your server won't save correctly (on exit) if you don't (unless you use a workaround like rconsole). Will you post a picture of the "zomboid.socket" file you have made? And what linux distro are you running?

 

Edit:

Please make sure that "pzuser" owns /opt/pzserver with chown pzuser: /opt/pzserver

 

Also please send a picture of the zomboid.service file aswell.

 

I would also like to know the output of "file /bin/sh"

 


I was just hunting you down and saw in google that you replied on my post LOL.

After doing some digging I found the problem on the steps, you may want to add the start order of the service and the zomboid.control socket.

Following the steps, if you start the zomboid service it will fail because we are missing the zomboid.control socket. You have to start the zomboid.control socket first so it is created so the zomboid.service to run proper. 

I went through 3-4 VMs until I figured out this was the case.

Link to comment
Share on other sites

3 hours ago, BeEatNU said:


I was just hunting you down and saw in google that you replied on my post LOL.

After doing some digging I found the problem on the steps, you may want to add the start order of the service and the zomboid.control socket.

Following the steps, if you start the zomboid service it will fail because we are missing the zomboid.control socket. You have to start the zomboid.control socket first so it is created so the zomboid.service to run proper. 

I went through 3-4 VMs until I figured out this was the case.

My understanding of SystemD is that this shouldn't be the case as a socket is not a service, they always exist, perhaps a simple "systemctl daemon-reload" would have sufficed, but I went ahead and added your suggestion to the wiki until I can do some further testing.

 

Edit: Also if you are still using the SystemD setup please append "KillSignal=SIGCONT"(see the wiki for an example) to your service file, this was a crucial oversight I made as it's necessary to stop systemd from terminating the process before the server has properly quit.

Link to comment
Share on other sites

Despite what the wiki says, the PZ server is a dedicated console application and doesn't support being run as a service. It requires the save and quit commands to shut down cleanly. This can be seen as a design oversight, but the short end of the stick is it's hard to predict how users will use your program and what the guide now teaches was not on our radar. 

So, in short, I don't really get why the wiki now instructs people to do it this way or when it was added that it should be run as a background process instead. If it's just about being able to have multiple server instances via SSH, then screen does the job well enough. If it's about hooking in management apps then I can see it, but without the above being clarified in the wiki, I think it's going to be a constant source of problems for us going forward. I worry that Linux novices are going to see these instructions and try to do something that's fairly complex compared to just install the server -> launch the server or lose data in the process, should they succeed.

 

I'm not suggesting it should be removed, but it might work better as its own page (like an advanced server guide such as "Run PZ Server as a Service" with proper cautions in place). Or a dedicated basics guide needs to be created (however this is usually the guide we've linked for the past several years, so that's not a good option.)

Link to comment
Share on other sites

Hi Enigma, the wiki has recommended this service setup since march of last year, the complication comes from the modifications to make it safe on shutdown, which I'm sure many people have never even run into as a problem as they likely just keep their server running for days on end and rollbacks are unlikely if players are constantly moving triggering the save when they leave an area. The wiki still has instructions on how to run the server as an attached process, and I've added some warnings to make it clear it is not the recommended method from the devs to run it as a systemd service.

Link to comment
Share on other sites

Depending on movement to ensure saving happens will not be reliable. That’ll only help for unloaded chunks.

 

That basically gurantees you’ll corrupt one or all of safehouses, metadata, zones, time .etc. Anyone connected at the time will not have their player data transferred and saved (requested by saveall) etc.

 

imo this explains a lot of issues with slot-based servers, assuming they followed the wiki’s earlier instructions.

Link to comment
Share on other sites

Sorry, I was mainly pointing out why you might not have seen this issue in the past, not recommending it as a reliable way to proc saving. I'm sure many admins have been confused by seemingly non-sensical rollbacks, using this scheme. But it does seem you have seen this issue before, so likely mystery solved for some mysterious save rollbacks.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...