Talk:Troubleshooting Servers

From Pavlov VR Wiki
Revision as of 05:47, 24 June 2023 by Rain (talk | contribs) (Created page with "> Check your CPU Clock Speed with I have never in my life seen troubleshooting ask for checking cpu clock speed. What would be the point of this? Maybe the user has under-clocked their server so much that it can not run Pavlov anymore? And they forgot about it so they have to be reminded to check the clock speed? I do not understand what the purpose of this step could possibly be except for some extremely rare and specific case in which the user is to blame? Please cla...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

> Check your CPU Clock Speed with

I have never in my life seen troubleshooting ask for checking cpu clock speed. What would be the point of this? Maybe the user has under-clocked their server so much that it can not run Pavlov anymore? And they forgot about it so they have to be reminded to check the clock speed? I do not understand what the purpose of this step could possibly be except for some extremely rare and specific case in which the user is to blame?

Please clarify what the point of this step is, because I would like to remove it as it seems to be completely useless to me.

> To monitor the logs (without heartbeat) from another terminal:

Why does this command use a different regex than the "To run the server without outputting the heartbeat" one? This should be consistent.

./PavlovServer.sh | sed '/heartbeat/d' and tail -f -n10000 /home/steam/pavlovserver/Pavlov/Saved/Logs/Pavlov.log | grep -v 'heartbeat'

Also, why 10k lines? That's a tad much? Maybe if it was piped into less, but it's in follow mode and definitely does not require 10k lines to fill the terminal. 100 lines would be the upper limit in my opinion.

And also, let's not include the full path to the log file, use relative paths instead because we do not know where the user has installed pavlov to.

tail -f -n 100 Pavlov/Saved/Logs/Pavlov.log | grep -v 'heartbeat'

And lastly, I do not believe this is even a relevant step anymore because the heartbeat is not logged anymore.

> Server won't start

The solution to run apt as sudo is only applicable to debian based systems. It would be advisable to just instruct the user to install the missing lib32gcc1 / libc++-dev libraries. They should know how to install software on their own system, so the specific instruction, that's only good for debian flavors, can be omitted.

If the File exists errors are harmless, they should not be listed here for troubleshooting. Besides, it says "File exists" and I'm pretty sure the users are smart enough to understand that this is acceptable behavior.

> Map wont load

The path to mod.io maps is not /tmp/workshop anymore and needs fixing to the correct path.

> Map wont load when running in a container

This is way too specific for the points listed, which can also just apply to non-container systems. We shouldn't care about whether the user runs the server inside a container or not.

Instead all three points here should be part of Map wont load

> Server stuck rotating forever

Again, way too specific. Run these two commands, those are 3 commands and are way too specific again. The user may not have steamcmd installed in ~/Steam. We should provide reasons for issues and the steps to resolve them.

For example:

You may be missing or have a wrong version of ~/.steam/sdk64/steamclient.so. The MD5 checksum of the correct steamclient.so is 65e2197528d2dc5c12f2354ec0269414.

If you find that you do not have the correct steamclient.so version, you can get it from steamcmd by installing Steamworks SDK Redist (AppId 1007) and copying the steamclient.so from Steamworks SDK Redist/linux64/steamclient.so.

---

I also believe strongly that if the steamclient.so is an issue, then there is an error message in the log file pointing to this.

So the first step installing the steamworks sdk redistributables, before checking for conflicting ports, is way overkill.

First step should be to identify the error from the log. Like, if the port is in use then it will say that the port is already in use, and the user should correspondingly be guided to checking their running pavlov servers for port conflicts.

Then, fixing the port conflicts here suggests that the server runs as a system.d service, which is again an assumption on the environment of the user, which we should not do.

The fix is to tell them that they have to change the port. The instructions to do so are on the dedicated server hosting page and do not belong here as that would make them redundant.

> Server - ping 999

Again, way too specific. Google Cloud Platform? Seriously?

We should tell the user that the reason for this issue usually is missing port access or block ICMP and to check for correct firewall/portforwarding/NAT.

> Can't connect to RCON

Again, too specific assuming paths and users of the user system.

Just indicating to the user, that they have to check their rcon settings and ports, should be plenty a pointer. The section about file access also is not helpful as it does not state what kind of permissions are required.

> PC ONLY - Map Download stops

This is redundant to Map wont load.