Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about expected behavior. #35

Open
laglink17 opened this issue Sep 11, 2023 · 2 comments
Open

Questions about expected behavior. #35

laglink17 opened this issue Sep 11, 2023 · 2 comments

Comments

@laglink17
Copy link

Hello, thanks for this great project! I'm trying to use for my self-hosted minecraft server.

I set it using the example from the project and it's working fine to start the server. A few things I noticed:

  • When "minPacketThreshold" is not set, it uses the default 30 packets. A Refresh from the Minecraft Client sends around 10 packets to check if the server is up. So, I think it should be set between 10 to 20 in this use case (minecraft server). Otherwise, the server (container) is not started without hitting refreshing like 3 o 4 times.

  • I set the "inactiveTimeOut" label in 600 seconds. According to the logs, when the last user disconnects from the server, it takes around 10 minutes to start checking if the container can be stopped. After that, the countdown beings and when the inactive time is reached, the container finally stops. As so, the time to stop the container is around 20 min. Is this the expected behavior?

Here are some logs:

DEBUG: 2023/09/11 20:47:24 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:47:24 group.go:169: 0 active clients DEBUG: 2023/09/11 20:47:54 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:47:54 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:47:54 group.go:169: 0 active clients DEBUG: 2023/09/11 20:48:24 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:48:24 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:48:24 group.go:169: 0 active clients DEBUG: 2023/09/11 20:48:54 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:48:54 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:48:54 group.go:169: 0 active clients DEBUG: 2023/09/11 20:49:24 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:49:24 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:49:24 group.go:169: 0 active clients DEBUG: 2023/09/11 20:49:54 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:49:54 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:49:54 group.go:169: 0 active clients DEBUG: 2023/09/11 20:50:24 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:50:24 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:50:24 group.go:169: 0 active clients DEBUG: 2023/09/11 20:50:54 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:50:54 group.go:49: 273011 packets received in the last 600 seconds DEBUG: 2023/09/11 20:50:54 group.go:169: 0 active clients DEBUG: 2023/09/11 20:55:25 group.go:49: 60864 packets received in the last 600 seconds DEBUG: 2023/09/11 20:55:25 group.go:169: 0 active clients DEBUG: 2023/09/11 20:55:55 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:55:55 group.go:49: 0 packets received in the last 600 seconds DEBUG: 2023/09/11 20:55:55 group.go:169: 0 active clients 30 / 600 seconds without an active client or sufficient traffic on running container DEBUG: 2023/09/11 20:56:25 group.go:71: ///////////////////////////////////////////////////////////////////////// DEBUG: 2023/09/11 20:56:25 group.go:49: 0 packets received in the last 600 seconds DEBUG: 2023/09/11 20:56:25 group.go:169: 0 active clients 60 / 600 seconds without an active client or sufficient traffic on running container

My other question here would be if there is a way to use the "active clients" from the logs to set a flag and be able to stop the container after a given time.

Just in case, I'll attach my compose file.

docker-compose.yml.txt

@vmorganp
Copy link
Owner

vmorganp commented Sep 25, 2023

Is that expected behavior?

Right now, yes though it may make sense to have a flag or change it if it's a popular opinion (no idea how to determine that, and not super eager to change the default behavior)

Is there a way to use the "active clients" from the logs to set a flag and be able to stop the container after a given time

I don't think I understand your question here. What would a timeline of this look like to you?

@laglink17
Copy link
Author

Is that expected behavior?

Right now, yes though it may make sense to have a flag or change it if it's a popular opinion (no idea how to determine that, and not super eager to change the default behavior)

Thanks for the answer! I have a better understanding about this part.

Is there a way to use the "active clients" from the logs to set a flag and be able to stop the container after a given time

I don't think I understand your question here. What would a timeline of this look like to you?

Sorry, english is not my main language. maybe that's way I was not clear enough.

What I tried to said is that from the logs, it seems like the "active clients" on the minecraft server can be read. If so, do you think a flag like "minPacketThreshold" can be added but for "active clients"? That way, the lazytainer can have another thing to check and stop the server container, for example, 10 minutes after having 0 active clients.

That would be my feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants