DJWoodZ / Satisfactory-Discord-Bot

A Discord bot that posts Satisfactory Dedicated Server status information such as online players.
MIT License
21 stars 2 forks source link

Install help #26

Closed spackletoe closed 10 months ago

spackletoe commented 10 months ago

I admit, this whole thing may be over my head as I don't know much about docker. I've tried to follow the instructions, which seem very well written, to the best of my abilities but I'm stuck not knowing how to get the .env.local file into the docker image? I think?

I'm still trying because this is EXACTLY what I want, and I don't know of any alternatives to try.

Here's my situation: I've just stood up an unraid server. I'm self-hosting a satisfactory dedicated server through a docker install I found on their "app store" (details here: https://forums.unraid.net/topic/79530-support-ich777-gameserver-dockers/)

I've been able to do the discord bot config, and modifying the .env.local is easy, I've installed all of the things you mentioned (git, node, docker desktop) but how do I get it up and running in a package for my server?

Can you give me any idea how to interpret things from my POV?

Thank you!

DJWoodZ commented 10 months ago

Hi @spackletoe,

Thank you for raising this. I am not an Unraid user, so please bear with me, and hopefully you can get it working.

Are you using the Docker Compose Manager plug-in for Unraid? This guide might be a good place to start for help with that: https://www.youtube.com/watch?v=7avhADqiPbc

If you tried following that, and you are still unable to run it, can you share more information on the steps you've taken and any error messages you are getting please?

spackletoe commented 10 months ago

Well using that got me further! But still stuck after I tried to Compose Up. See attached.

image

Thanks for your help!

DJWoodZ commented 10 months ago

That looks to be an error related to Unraid or the Docker Compose Manager plug-in. It is basically saying it cannot find the Dockerfile at the expected location and it appears similar to the errors shown here:

Both seem to suggest the error will appear after after a reboot, due to Unraid using a RAMDisk. So I guess the first question is, have you rebooted the host since you built the docker image? If that's the case, in order to make it persist, you'll probably have to create a script to recreate it after a reboot.

Other advice, which doesn't appear to be directly related to your issue, includes disabling Buildkit, but I'm unsure if that will help: https://iq.opengenus.org/failed-to-solve-with-frontend-dockerfile-v0/

Maybe trying to get it running through Unraid is complicating things though. I think you have a few options:

Something else you could try would be to not use Docker Compose, but use docker run instead. I'm unsure how Unraid supports this, but the included compose.yaml converted to a docker run command would be this. You'd obviously have to ensure the paths are correct though:

docker run -v ./docker-volumes/db/:/usr/src/app/db/ -v /opt/satisfactory/config/gamefiles/FactoryGame/Saved/Logs/FactoryGame.log:/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log:ro --env-file ./.env --env-file ./.env.local -e NODE_ENV=production -e SATISFACTORY_BOT_DB_PATH=/usr/src/app/db/db.json -e SATISFACTORY_BOT_LOG_LOCATION=/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log 
spackletoe commented 10 months ago

Oh man, we are getting close! I have successfully got the container runnning, here's the log I got when it composed:

image

Now that it's a container that shows up in my docker container list, I can have it startup when my server starts up, which is great. I've added the bot to my discord and given it the send messages permission. Things seem to be running... but there is no messages created in discord when there is server activity.

Are there any logs that are being generated by your code that I can look at to try to track down where something isn't right?

Really appreciate your help!

DJWoodZ commented 10 months ago

That's great. It seems you are getting there. You can use the docker logs command to see the logs for a container. You need to specify the container name as an argument (which you can get from docker ps), like this:

docker logs satisfactory_discord_bot-server-1

If your FactoryGame.log has activity when you join the game, etc. (verify that with tail -f {path to FactoryGame.log}) but the discord bot is not responding to it, you can try enabling the watchFile mode by setting this in your .env.local file:

SATISFACTORY_BOT_LOG_USE_WATCH_FILE=true
spackletoe commented 10 months ago

Well that certainly showed me something, but I'm not sure how to fix it.

Node.js v20.11.0
node:internal/modules/cjs/loader:1147
  throw err;
  ^

Error: Cannot find module '/usr/src/app/bin/server.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
    at node:internal/main/run_main_module:28:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

I looked in the bin folder and server.js wasn't there, so I put it there. But it's not exactly at that path. If it's really looking in /usr/src/app/ I don't think that path is right. Where would I fix this? I'm really unsure if things are in the right places. The paths are confusing, but things must be generally in the right place since things are compiling and running. right?

DJWoodZ commented 10 months ago

The /usr/src/app path refers to a path inside the container. It is commonly used in Node containers as the working directory. It is specified in the Dockerfile: https://github.com/DJWoodZ/Satisfactory-Discord-Bot/blob/main/Dockerfile#L29

That error implies that the image did not build correctly. Did you get any errors during the build step? You may wish to try building it again to see if you can spot any errors.

If if does appear to be building correctly, you can interact with the container via an interactive shell. To do that, you can run a command like this (where satisfactory_discord_bot-server-1) is the name of your container:

docker exec -it satisfactory_discord_bot-server-1 /bin/sh
spackletoe commented 10 months ago

You have been a huge help! Progress has been made. I re-built and it seems to have gone better this time. That error isn't around anymore. BUT... I'm not in the promise land yet. The bot only posts this message, when/if the server is restarted. But no others.

image

Do you have a "buy me a cup of coffee link" or anything? ...your time shouldn't be free!

DJWoodZ commented 10 months ago

That's great. It probably just means it's not seeing the log file being updated.

Firstly, I recommend using an interactive shell to check that the log file is mapped/accessible inside the container, using this command:

docker exec -it satisfactory_discord_bot-server-1 /bin/sh

Within the container, you should find the log file at this location:

/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log

If the log file is not there, check your docker config to ensure the path is mapped correctly. There are some details on that in the README.

Next, use this command to tail the log to ensure it updates when there is activity in the Satisfactory Dedicated Server (so try joining the Satisfactory Dedicated Server after running this command to check for activity):

tail -f /home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log

Remember to exit the container to return to the host's shell:

exit

If it was not being updated inside the container, double check the log file location and permissions.

If the log file was being updated, try re-running the container with the SATISFACTORY_BOT_LOG_USE_WATCH_FILE option toggled.

So if SATISFACTORY_BOT_LOG_USE_WATCH_FILE is currently set to false in your .env.local file, try setting it to:

SATISFACTORY_BOT_LOG_USE_WATCH_FILE=true

Or if SATISFACTORY_BOT_LOG_USE_WATCH_FILE is currently set to true in your .env.local file, try setting it to:

SATISFACTORY_BOT_LOG_USE_WATCH_FILE=false

After changing that setting, remember to restart the container (or do a re-build for good measure).

That is very kind. ❤️ Here is my By Me a Coffee page.

spackletoe commented 10 months ago

hmm.. first off, flipping that WATCH_FILE back to false did something, once i did that I started getting these:

image image

But I'm still not seeing connections. So I looked into that path thing. I'm confused on this one. if I use the unraid main console, this command works... tail -f /mnt/user/appdata/satisfactory/FactoryGame/Saved/Logs/FactoryGame.log I tried putting a few variations of that in the SATISFACTORY_BOT_LOG_LOCATION variable of .env.local but it doesn't seem to be picking it up.

DJWoodZ commented 10 months ago

When you start/stop the server, you will see the online/offline messages because the bot probes the server's query port to get that information (the SATISFACTORY_BOT_SERVER_IP, SATISFACTORY_BOT_SERVER_QUERY_PORT and SATISFACTORY_BOT_SERVER_QUERY_TIMEOUT_MS options relate to that). That part seems to be working for you.

The join/left messages are determined by reading the log file. As mentioned here, the SATISFACTORY_BOT_LOG_LOCATION is ignored when using Docker Compose. That is because it is hard-coded in the compose.yaml. That is necessary to make it work. This relates to the path inside the container, and should not need to be edited.

If the log file path on the host is incorrect, you would need to edit this line. You will need to replace the first path (/opt/satisfactory/config/gamefiles/FactoryGame/Saved/Logs/FactoryGame.log) with the correct path of the file, as it is located on the host.

Therefore, if the path on the host is: /mnt/user/appdata/satisfactory/FactoryGame/Saved/Logs/FactoryGame.log, that line should read:

- /mnt/user/appdata/satisfactory/FactoryGame/Saved/Logs/FactoryGame.log:/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log:ro

The second path (/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log:ro) refers to where the log file gets mapped to inside the container. So long as it matches this line, which it does by default, you should not need to edit it.

The :ro at the end simply ensures the container can only read the file (read-only).

spackletoe commented 10 months ago

Did all that... still not working. I checked any logs I can find and the only errors I see anywhere are:

when I click on Unraid's option to "Update Stack", which I think is re-building the container.

image

-- here's what I get:

[+] Pulling 1/0
 ✔ server Skipped - No image to be pulled                                                                                                        0.0s 
[+] Building 1.9s (13/13) FINISHED                                                                                                     docker:default
 => [server internal] load build definition from Dockerfile                                                                                      0.1s
 => => transferring dockerfile: 76B                                                                                                              0.0s
 => [server internal] load .dockerignore                                                                                                         0.1s
 => => transferring context: 79B                                                                                                                 0.0s
 => [server] resolve image config for docker.io/docker/dockerfile:1                                                                              0.9s
 => CACHED [server] docker-image://docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021         0.0s
 => [server internal] load build definition from Dockerfile                                                                                      0.0s
 => [server internal] load metadata for docker.io/library/node:20-alpine                                                                         0.6s
 => [server internal] load .dockerignore                                                                                                         0.0s
 => [server internal] load build context                                                                                                         0.1s
 => => transferring context: 1.28kB                                                                                                              0.0s
 => [server stage-0 1/4] FROM docker.io/library/node:20-alpine@sha256:2f46fd49c767554c089a5eb219115313b72748d8f62f5eccb58ef52bc36db4ad           0.1s
 => => resolve docker.io/library/node:20-alpine@sha256:2f46fd49c767554c089a5eb219115313b72748d8f62f5eccb58ef52bc36db4ad                          0.1s
 => CACHED [server stage-0 2/4] WORKDIR /usr/src/app                                                                                             0.0s
 => CACHED [server stage-0 3/4] RUN --mount=type=bind,source=package.json,target=package.json     --mount=type=bind,source=package-lock.json,ta  0.0s
 => CACHED [server stage-0 4/4] COPY . .                                                                                                         0.0s
 => [server] exporting to image                                                                                                                  0.0s
 => => exporting layers                                                                                                                          0.0s
 => => writing image sha256:dcc3889fac56f0f01461078864343e0252db61684991604d2c5f2ec64f2972fc                                                     0.0s
 => => naming to docker.io/library/satisfactorydiscordbot-server                                                                                 0.0s
WARN[0000] buildx: failed to read current commit information with git rev-parse --is-inside-work-tree 
[+] Running 1/0
 ✔ Container satisfactorydiscordbot-server-1  Started                                                                                            0.0s 

That warning at the end there mean nything?

Then also, if I view the container's logs, I see this repeated a few times. (This log not having a timecode makes it hard to know what's new.)

satisfactorydiscordbot-server-1  | Node.js v20.11.0
satisfactorydiscordbot-server-1  | Poll interval: 60000 milliseconds
satisfactorydiscordbot-server-1  | Found: /usr/src/app/db/db.json
satisfactorydiscordbot-server-1  | Logging out
satisfactorydiscordbot-server-1  | /usr/src/app/node_modules/@discordjs/ws/dist/index.js:1439
satisfactorydiscordbot-server-1  |       throw new Error(
satisfactorydiscordbot-server-1  |             ^
satisfactorydiscordbot-server-1  | 
satisfactorydiscordbot-server-1  | Error: Not enough sessions remaining to spawn 1 shards; only 0 remaining; resets at 2024-01-31T08:49:36.909Z
satisfactorydiscordbot-server-1  |     at WebSocketManager.connect (/usr/src/app/node_modules/@discordjs/ws/dist/index.js:1439:13)
satisfactorydiscordbot-server-1  |     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
satisfactorydiscordbot-server-1  |     at async WebSocketManager.connect (/usr/src/app/node_modules/discord.js/src/client/websocket/WebSocketManager.js:207:5)
satisfactorydiscordbot-server-1  |     at async Client.login (/usr/src/app/node_modules/discord.js/src/client/Client.js:228:7)
satisfactorydiscordbot-server-1  | 
satisfactorydiscordbot-server-1  | Node.js v20.11.0

Are these relevant? any other place I can look to troubleshoot?

DJWoodZ commented 10 months ago

On the docker warning, you can try running git status in the project directory. That might give you some information about why you are seeing that warning.

I am less certain on the second one, but that looks to be a Discord error. This is a guess but perhaps is was throttling connection attempts, and telling you to wait until after '2024-01-31T08:49:36.909Z' before trying again?

The default restart policy for this project is to always restart the container unless you stop it. Perhaps check older logs to see if there was a repeated error which caused the container to stop/start and the bot to re-connect multiple times in a short space of time. If that was the case, the multiple connection attempts may have caused that.

To get to the bottom of why that is happening, and to stop the same thing from happening, I recommend temporarily removing this line from the compose.yaml file:

restart: unless-stopped

Details on that option can be found here: https://docs.docker.com/compose/compose-file/compose-file-v3/#restart

This will mean, the next time you attempt to start it, Docker will not try to restart it if there is an error. If there is a similar restart policy setting in Unraid or the Docker Compose Manager plug-in, I suggest setting that to 'none' (or equivalent) for the container also.

The next time you start it, if it stops, the latest log will hopefully make it clearer as to why that happened. If you get the same error as above, ensure the container is stopped and try waiting until the stated time has passed before trying again.

spackletoe commented 10 months ago

Progress again, but still no posts to discord, no even the server is down stuff anymore. The log for the container looks pretty clean, but it doesn't realize when someone joins the werver, despite that one entry last night. I've tried joining again and it just says "Updating..."

(BTW, I had used these logs to recognize the permissions error and fixed that!)

image
DJWoodZ commented 10 months ago

The 'Updating...' messages refer to the network polling. That is shown when it is checking whether the server is online or offline. There is no equivalent for when it reads the log file, because the log file is read in real time.

Messages like this, simply mean the relevant entries have been seen in the log:

Join request ...
Join succeeded ...

It has to parse the log file from the start each time it starts, but it will only send a message if the date of the log entry is new. If it spots a new log entry and attempts to send a message, you will see entries like this:

Sending message to: ...

The EACCES error above suggests there was an error with the log file mapping or file permissions on the host.

The Log file open {date} should match the first line of the actual log file (which should read Log file open, {date}). This should match the time the dedicated server last started/restarted. You can compare those 3 things to ensure that the log file being read by the bot is the latest. If it appears the discord bot is reading an older log file, you should check the dedicated server can actually write to its log file, and that no intermediary mounts are limiting access.

Using a combination of the 'Log file open' dates and tail -f, I suggesting working step-by-step from the dedicated server to the discord bot, to ensure the file is being written correctly at the source and at any mount point along the way (e.g. from inside the game server docker container, to the host mount point, and inside the discord bot's docker container).

spackletoe commented 10 months ago

Okay, coming back to report that I have checked that the FactoryGame.log is updating and the paths in the compose.yaml (and docker-compose.yml since this is the compose file unraid seems to want to use) - just in case, these two files are identical... this is what thwy contain:

services:
  server:
    build:
      context: .
    environment:
      NODE_ENV: production
      SATISFACTORY_BOT_DB_PATH: /usr/src/app/db/db.json
      SATISFACTORY_BOT_LOG_LOCATION: /home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log
    env_file:
      - ./.env
      - ./.env.local
    volumes:
       - ./docker-volumes/db/:/usr/src/app/db/
       - /mnt/user/appdata/satisfactory/FactoryGame/Saved/Logs/FactoryGame.log:/home/steam/SatisfactoryDedicatedServer/FactoryGame/Saved/Logs/FactoryGame.log:ro
    restart: unless-stopped

I have also verified that a player joining gets updated in the log file, which I confirmed using the tail command with both the server's mount point path and from within the container shell at the /home/steam path.

WAIT A DANG SECOND. I just rechecked, re-uploaded and re-built everything and.... yahtzee!

image

I know I'm a noob at this stuff, but I've learned a ton fom this thread. Thank you for being patient and thorough. I really appreciate it!

DJWoodZ commented 10 months ago

That's great and you're welcome. I'm glad you got it working. If you experience any other issues, do not hesitate to create another issue. Have fun.