Attaching to the server console

[docent-net]

Currently, there is no possibility to attach to the console. Normally admins create server processes over GNU screen session which is a very bad idea (as there is no true process management then).

The idea is to run server in a systems unit providing a TTY for the process in a way one another process could communicate bi-directly with the server service. Some helper URLs:

• https://stackoverflow.com/questions/40812634/send-stdout-stderr-to-console-for-a-systemd-service
• https://www.freedesktop.org/software/systemd/man/systemd.exec.html
• https://unix.stackexchange.com/questions/428474/attach-to-tty-running-a-process
• https://technostuff.blogspot.com/2008/10/some-useful-socat-commands.html
• https://www.linux.com/news/socat-general-bidirectional-pipe-handler/
• https://unix.stackexchange.com/questions/179827/is-it-possible-to-open-a-terminal-with-specified-tty-pty
• or via tmux?
• https://unix.stackexchange.com/questions/423334/reading-writing-to-tty-using-systemd

[gilesknap]

I think this answers my question re console in another thread.

I managed to implement some rudimentary but very useful command completion for my console attached process (using screen readline). Maybe this would be a nice feature for your console?

[docent-net]

Hi Giles,

The idea is not to use neither screen nor tmux, as the assumption is that the server process should be a child of systemd (an init system). This way systemd can control it (e.g. restart when dead), have direct access to logs, unit file defines exactly the environment under which server will run (e.g. environment variables, memory limits, commands that should be run before starting and after shutdown) etc.

Using screen/tmux makes systemd unaware what's exactly happening to the server process. It might be lost, it may misbehave (e.g. use too much of RAM) and systemd will not act. It will just make sure that screen/tmux process is running properly. And screen/tmux shouldn't be doing the work of the init process :)

Systemd has some features which enable 2 - way communication with a process. However, this is not a simple thing to do, thus I'm still not sure how it will work (some URLs mentioned above tell me, that it is possible).

As a workaround, for now, I simply put my kid's nickname to the ops.json file, making him an OP. Thanks to this he is able to operate admin commands from the game console.

[gilesknap]

I take the point about screen and tmux.

My games are being played by 8 year olds and I have found that giving them admin rights appears to cause arguments. So I allow Noah to come to me if they have got really stuck and i'll provide a teleport or similar through the server commands on my phone. It is quite nice to be able to provide this service without requiring I start up an MC client.

It also gives me a quick way to check if any of Noah's friends have connected to the server, so I can let him know.

Is the issue that screen detaches from the parent process? My command line completion service is in python and launches MC server with popen. I could probably modify it to take its I/O through a port. Would systemd be able to look after the child process?

[gilesknap]

I guess there is also the rcon for this sort of thing. but I've not looked at that yet.

[gilesknap]

in fact there is already a python library for rcon. https://github.com/uncaught-exceptions/mcrcon

[docent-net]

Wow, rcon looks awesome - thanks! I really didn't like the whole idea of writing and reading from the process stdin/out, so this would be the ideal way :)

On Sat, May 2, 2020 at 10:13 PM Giles Knap notifications@github.com wrote:

in fact there is already a python library for rcon. https://github.com/uncaught-exceptions/mcrcon

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/docent-net/mc-server-manager/issues/9#issuecomment-623007440, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUFGSOW22HFNJWYTFK7BULRPR5HZANCNFSM4MRLHUAQ .

[docent-net]

TIL: RCON is a standard for interactions with game servers' console: https://developer.valvesoftware.com/wiki/Source_RCON_Protocol