Discord webhook script does not detect connects/disconnects while main server is being stopped about mcscripts

[TapeWerm]

As seen on journalctl -eu mcbe@MCBE (-o short-iso-precise gives more granular time):

Jul 01 19:04:15 glados bash[20617]: [2020-07-01 19:04:15 INFO] Player connected: xXredactedXx, xuid: REDACTED
Jul 01 19:04:42 glados MCstop.sh[22142]: Server stopping in 10 seconds
Jul 01 19:04:42 glados systemd[1]: Stopping Minecraft Bedrock Edition server @ MCBE...
Jul 01 19:04:49 glados MCstop.sh[22142]: Server stopping in 3 seconds
Jul 01 19:04:50 glados MCstop.sh[22142]: Server stopping in 2 seconds
Jul 01 19:04:51 glados MCstop.sh[22142]: Server stopping in 1 seconds
Jul 01 19:04:52 glados systemd[1]: Stopped Minecraft Bedrock Edition server @ MCBE.
Jul 01 19:04:52 glados bash[20617]: [2020-07-01 19:04:52 INFO] Server stop requested.
Jul 01 19:04:52 glados bash[20617]: [2020-07-01 19:04:52 INFO] Stopping server...
Jul 01 19:04:52 glados bash[20617]: Quit correctly
Jul 01 19:05:01 glados systemd[1]: Started Minecraft Bedrock Edition server @ MCBE.
Jul 01 19:05:01 glados bash[22153]: NO LOG FILE! - Failed to up file descriptor limit Operation not permitted
Jul 01 19:05:01 glados bash[22153]: NO LOG FILE! - setting up server logging...
Jul 01 19:05:01 glados bash[22153]: [2020-07-01 19:05:01 INFO] Starting Server
Jul 01 19:05:01 glados bash[22153]: [2020-07-01 19:05:01 INFO] Version 1.16.1.2

I noticed this today as well actually. 19:04 to be exact. Thanks for the attention to detail, it's good to know there are other eyes to find these issues. I do not see a disconnect in the logs, so I do not think there is anything to go off of. And yeah, mcbe-log will stop with mcbe. I could easily change that but don't see any gains from it.

I do not know a way to reliably find what players are currently on the server. You could scrape the joins and disconnects since the server started but I don't know how long journalctl backscroll will last, probably long enough but I'd rather not rely on it. I also know this scraping can actually be quite slow, the time command on a script that parses journalctl output can get slow depending on how complicated the parsing gets. MCBEbackup.sh used to be several seconds slower until I simplified it.

The most likely solution is to make the mcbe-log service independent from the mcbe service. Then it could post messages when the server starts and stops. You could assume everyone connected disconnects when the server stops. And whether or not mcbe-log is independent from mcbe it could easily post kick messages with some modification. I'm not super interested in adding this, but if you want you can make a pull request. Thanks!

Edit: I wonder if Before=mcbe@%i.service in the [email protected] file would make mcbe-log stop after mcbe, so it could post the server stop message. It might need PartOf=mcbe@%i.service to stop with it if so.

Edit 2: Yes, Before= works and PartOf= is not even needed. So server stop messages could be posted even if the bot died with the server, it just needs to start before and die after the server. mcbe-bot would also need to start before the server as well so the mcbe-log would be able to start after it, otherwise an ordering conflict would happen.

[TapeWerm]

Eh, it's easy enough work that I may as well do it myself. Don't bother with a pull request unless you want the practice, and if you do reply before whenever I get off my butt PM tomorrow. Otherwise I'll make the changes.

[jared-hess]

Sure, works for me :)

[TapeWerm]

23:05:41 MCBE_Bot | Server MCBE started
23:05:48 MCBE_Bot | Vincent294 connected to MCBE
23:06:03 MCBE_Bot | Vincent294 was kicked from MCBE because What do you think, we allow Arch users here? Get a real distro kiddo.
23:06:03 MCBE_Bot | Vincent294 disconnected from MCBE
23:06:11 MCBE_Bot | Server MCBE stopping

Seems functional, shellcheck approves, journalctl logs look appropriate, commit incoming.

[TapeWerm]

I should note I base server stop messages off systemd messages. You could stop the server via its console command stop and that would not send a message via mcbe-log. Only systemctl stop mcbe@MCBE would make a log entry mcbe-log would post. However the server message 'Server stop requested' leaves less than a second for mcbe-log to post a message, so I try to avoid that. One solution would be to make an ExecStop=/bin/sleep 3 in [email protected] so it has time to send the server stop message before it gets killed. My solution is to just deal with it, if you're stopping the server via the console you're doing it by hand. The only good use case is a 0 second shutdown warning.

@@@ systemd message below @@@
2020-07-02T00:08:50.876796-0700 glados systemd[1]: Stopping Minecraft Bedrock Edition server @ MCBE...
2020-07-02T00:08:50.950990-0700 glados MCstop.sh[17948]: Server stopping in 10 seconds
2020-07-02T00:08:57.953859-0700 glados MCstop.sh[17948]: Server stopping in 3 seconds
2020-07-02T00:08:58.958402-0700 glados MCstop.sh[17948]: Server stopping in 2 seconds
2020-07-02T00:08:59.963528-0700 glados MCstop.sh[17948]: Server stopping in 1 seconds
@@@ server message below - 09:00.983933 @@@
2020-07-02T00:09:00.983933-0700 glados bash[7188]: [2020-07-02 00:09:00 INFO] Server stop requested.
2020-07-02T00:09:00.984777-0700 glados systemd[1]: Stopped Minecraft Bedrock Edition server @ MCBE.
@@@ SIGTERM sent to MCBElog.sh - 00:09:00.986378 @@@
@@@ Only 0.002445 seconds to post a server stop message to Discord/IRC @@@
2020-07-02T00:09:00.986378-0700 glados systemd[1]: Stopping Post Minecraft Bedrock Edition server logs to chat @ MCBE...
2020-07-02T00:09:00.990102-0700 glados sudo[17945]: pam_unix(sudo:session): session closed for user root
2020-07-02T00:09:01.001158-0700 glados systemd[1]: Stopped Post Minecraft Bedrock Edition server logs to chat @ MCBE.
2020-07-02T00:09:01.001573-0700 glados systemd[1]: Stopping Minecraft Bedrock Edition server IRC bot @ MCBE...
2020-07-02T00:09:01.017043-0700 glados systemd[1]: Stopped Minecraft Bedrock Edition server IRC bot @ MCBE.
2020-07-02T00:09:01.029407-0700 glados bash[7188]: [2020-07-02 00:09:01 INFO] Stopping server...
2020-07-02T00:09:01.293748-0700 glados bash[7188]: Quit correctly

[TapeWerm]

Never mind, I find this trade-off worth it and have made the deal. Good night!