Linux – Sending Text Input to a Detached Screen

gnu-screenlinux

I'm trying to run a minecraft server on my unRAID server.

The server will run in the shell, and then sit there waiting for input. To stop it, I need to type 'stop' and press enter, and then it'll save the world and gracefully exit, and I'm back in the shell. That all works if I run it via telnetting into the NAS box, but I want to run it directly on the box.

this is what I previously had as a first attempt:

#define USER_SCRIPT_LABEL Start Minecraft server
#define USER_SCRIPT_DESCR Start minecraft server. needs sde2 mounted first
cd /mnt/disk/sde2/MCunraid
screen -d -m -S minecraft /usr/lib/java/bin/java -Xincgc -Xmx1024M -jar CraftBukkit.jar

MCunraid is the folder where I have the Craftbukkit.jar and all the world files etc. If I type that screen line in directly, the screen does setup detached and the server launches. If I execute that line from within the script it doesn't seem to set up a screen

for stopping the server, I need to 'type' in STOP and then press enter. My approach was

screen -S minecraft -X stuff "stop $(echo -ne '\r')"

to send to screen 'minecraft' the text s-t-o-p and a carriage return. But that doesn't work, even if I type it directly onto the command line. But if I 'screen -r' I can get to the screen with the server running, then type 'stop' and it shuts down properly.

The server runs well if I telnet in and do it manually, just need to run it without being connected from my remote computer.

Best Answer

I can solve at least part of the problem: why the stop part isn't working. Experimentally, when you start a Screen session in detached mode (screen -d -m), no window is selected, so input later sent with screen -X stuff is just lost. You need to explicitly specify that you want to send the keystrokes to window 0 (-p 0). This is a good idea anyway, in case you happen to create other windows in that Screen session for whatever reason.

screen -S minecraft -p 0 -X stuff "stop^M"

(Screen translate ^M to control-M which is the character sent by the Enter key.)

The problem with starting the session from a script is likely related to unMENU.

Related Solutions

GNU Screen – Using -dmS Option to Run Background Jobs Stably

You would only use -dm if you want to run a command in a screen session and not enter it interactively

-S is just to give the session a usable name so you can reconnect to it again easily later

If you want to use it interactively and don't want to give it a human readable name, you can omit all of those arguments safely.

For example, if you just want to start up screen to run the command, say, /path/to/longTime and you don't want to watch it run you could do it either as

screen -dmS longSession /path/to/longTime

or you could do

screen -S longSession
$ /path/to/longTime

ctrlad

Both would accomplish the same thing, but one is both easier to script and a bit less typing.

Systemd – Stop Systemd Service by Sending Command to Screen Session

You probably don't want to use screen to daemonize inside of systemd because systemd assumes certain things about how a process works, particularly in oneshot mode. From the systemd.service(5) documentation:

Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units. RemainAfterExit= is particularly useful for this type of service. This is the implied default if neither Type= nor ExecStart= are specified.

Your process isn't exiting immediately, so oneshot isn't the correct behaviour to look for.

Looking at bigly --help:

usage: [options] [torrent [torrent ...]]
 -h,--help        Show this help.
 -u,--ui <uis>    Run <uis>. ',' separated list of user interfaces to run
                  (swt, console, telnet). The first one given will respond
                  to requests without determinable source UI (e.g. further
                  torrents added via command line).
    --closedown   shutdown an existing instance of BiglyBT
    --shutdown    shutdown an existing instance of BiglyBT
    --open        show the BiglyBT interface
    --share       share a resource

Bigly is able to start in telnet mode, which should be good enough to run as its own daemon without any extra help; it can then talk to a running instance to send a shutdown command using --shutdown. Taking this into account, we can run the service in simple mode (I excluded classpath references and command line options that weren't required to run, so add them back if you need them):

bigly.service:

[Unit]
Description=BiglyBt daemon
After=network-online.target

[Service]
Type=simple
User=pi
ExecStart=/usr/bin/java -cp /home/pi/biglybt_stock/BiglyBT.jar -Djava.library.path=/home/pi/biglybt_stock -Dbiglybt.install.path=/home/pi/biglybt_stock -Dazureus.script=/home/pi/biglybt_stock/biglybt -Dazureus.config.path=/home/pi/.biglybt_stock  com.biglybt.ui.Main --ui=telnet
#ExecStop=/usr/bin/java -cp /home/pi/biglybt_stock/BiglyBT.jar -Djava.library.path=/home/pi/biglybt_stock -Dbiglybt.install.path=/home/pi/biglybt_stock -Dazureus.script=/home/pi/biglybt_stock/biglybt -Dazureus.config.path=/home/pi/.biglybt_stock  com.biglybt.ui.Main --shutdown
#SuccessExitStatus=143
ExecStop=/bin/sh -c "nc 127.0.0.1 57006 <<< 'quit iamsure'"

[Install]
WantedBy=multi-user.target

~~The process exits with an exit code of 143, so I noted that as the success condition for the service.~~ As --shutdown doesn't seem to work in telnet mode, I used netcat to send the quit command to the telnet server (port 57006 appears to be the default.) As well, there were a number of error conditions at startup, but I was looking at getting the program running so I ignored them.

The telnet interface binds to all interfaces, so you may want to set up a firewall rule to prevent outside connections.

Best Answer

Related Solutions

GNU Screen – Using -dmS Option to Run Background Jobs Stably

Systemd – Stop Systemd Service by Sending Command to Screen Session

Related Question