Return to Revisions

Here's some minor modifications:

1. Since it listens on a network socket, make it a dependency of network.target.
2. nohup is not needed since systemd will daemonize the executable for you.
3. I think a separate shell script would be an overkill, so just merge it into the service file.
4. Redirection (< /dev/null and so forth) isn't needed since systemd sets up an appropriate standard I/O context. Indeed, if you take the redirection out systemd will log anything sent to standard output by the Java program in its journal, with no special logging mechanism required.
5. Running asynchonously from the invoking shell (&) isn't needed or appropriate.
6. There's a specific behaviour pattern required by Type=forking, and if it isn't followed by the dæmon things go wrong. So try for Type=simple (or Type=notify).

So the service file looks like this:

[Unit] Description=Some job After=network.target [Service] WorkingDirectory=/home/user/tmp/testout SyslogIdentifier=SocketTest ExecStart=/bin/sh -c "exec java -jar /home/user/programming/tests/java/core/SocketTest/SocketTest.jar" User=dlt Type=simple [Install] WantedBy=multi-user.target 

Notes:

1. You cannot just use java as the name of the program to run. systemd doesn't search PATH for executables, and the name of the executable given to ExecStart must be absolute. So if you want path searching you have to invoke via a shell or /usr/bin/env. We choose /bin/sh here.
2. Because this is Type=simple the shell must exec Java, not run it as a child process. systemd controls the service through the main process, and that needs to be Java, not a parent shell process.
3. Because this isn't invoking the Java executable directly, systemd will put the name sh in its journal as the service name. See How to avoid /usr/bin/env being marked in systemd logs as the executable for more on this.

As far as I know, there is no special caveat of running Java application with Systemd.