Environment="USER=ubuntu" "Path=/home/ubuntu/console/bin"
WorkingDirectory=/home/ubuntu/console/bin
ExecStart=/bin/sh -ec "exec /sbin/start-stop-daemon -S -c ${USER} -d ${Path} --pidfile=/var/run/console.pid --oknodo --exec consoleExecutable " #2>/dev/null
ExecStop=/bin/sh -ec "exec /sbin/start-stop-daemon -K --quiet -c ${USER} -d ${Path} --pidfile=/var/run/console.pid --retry=TERM/30/KILL/5 --oknodo --exec consoleExecutable" #2>/dev/null
This is almost worthy of the systemd House of Horror. Were it not the case that there's a horror story already in there that does this.
Do not use start-stop-daemon in a service unit to do all of the things that a service unit already does. With unnecessary PID files and the wrongheaded assumption that ExecStart accepts shell syntax comments, no less.
And do not do what the other answer says and try to bodge it with Type=forking. That makes things worse, not better.
The nonsense with start-stop-daemon is why things are going wrong. Because the process running start-stop-daemon does not become the service, but in fact exits pretty much imediately, systemd is thinking that your service is terminating. In your first systemctl status output, you can see that systemd is in the middle of sending SIGTERM to clean up all left-over running processes after running the ExecStop action, which is what it does when it thinks that a service has terminated.
Just do things simply:
Type=simple
WorkingDirectory=/home/ubuntu/console/bin
User=ubuntu
ExecStart=/home/ubuntu/console/bin/consoleExecutable
No ExecStop nor Environment is actually required.
Further reading
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
You can put an executable file in
/lib/systemd/system-sleep/and it will be run on suspend with the 2 argspreandsuspend, and again after resume withpostandsuspend. The systemd man page says this is a hack.To use a systemd Unit, see my later answer to a similar question.