Issue on Linux, needs to kill server even after "EXIT" for it to properly stop

[Neptnium]

Fill out general information
OS (windows, linux, ...): Linux (was only tested on debian)
BeamMP-Server Version: Latest (v3.9.3)

Describe the bug
In Pteoradctyl, when a server is stopped, it is doing the stopping process, but it never ends, you need to KILL it or send a console input. (See vids below)

To Reproduce
https://github.com/user-attachments/assets/30b7a166-cd49-4263-a04b-bc65e76a25a7
https://github.com/user-attachments/assets/a70c5dc5-bd29-4ac2-b1d8-2cecd225d907

Expected behavior
The server to stop correctly, and no need to kill it.

[StanleyDudek]

If it helps, I guess I have the same behavior, not pterodactyl

In just plain ol Debian 13
~/Servers/TEST $ ./BeamMP-Server
Server runs
exit
Server shuts down, but does not return me to shell input, a single enter keystroke does

Same behavior in Docker on Debian 13, where I expect a restart after shutdown

On Windows, the process exits and the server closes after the shutdown, and so the server can reliably restart when exited with any typical method

[leofleeo]

this is normal for beamMP, I have been trying to make a beamMP server management web panel and it has been frustrating me SOOOO MUCH

[leofleeo]

I beleive this is for the after shutdown scripts that mods can run

[lionkor]

Just adding some context;

Shutdown has always been kind of an issue. This is because lots of unrelated, uncoordinated processes need to "figure out" that they're supposed to shut down, and then shut down. This is difficult for some systems, as they might be e.g. reading from a network connection, and thus they will "miss" this information until they're done doing whatever they are doing.

There is a "simple" fix for this, which, as mentioned in the logs, is to send the shutdown signal multiple times, at which point the server has a mechanism to kill itself.

I'm not sure what pterodactyl sends on shutdown, but it looks like it sends SIGTERM? Either way, sending it multiple times should kill the server if it's stuck. A fix could be to trigger this same behavior some N number of seconds after Lua's onShutdown has fired and players have been kicked. At that point it should be fairly safe to force shutdown automatically.

[lionkor]

When I built that mechanism, I also introduced this shutdown handler thing where different threads are supposed to register their shutdown handler, but it's simply a fact that not all long-running tasks inside the server are cleanly cancelable.

As such, a reasonable middle-ground would be to register a shutdown handler that waits until onShutdown is done, and all players are kicked (maybe this can be done by querying subsystem statuses) and then count to 5 and simply std::exit(0).