Thanks Raedwald. I studied the post you mentioned and I finally resolved it.

Here the steps I did.

startapp.sh

#!/bin/bash
java -jar /home/usr/local/bin/vedioplayer.jar

created the above script and saved it in /etc/init.d make sure you allow execution of the shell script.

  sudo chmod +x /etc/init.d/startapp.sh

After that run the follwing command

  sudo update-rc.d startapp.sh defaults 98 02

Also you can add the script to Startup Applications list from Applications.

How about you use the crontab?

As the user you want the jar to run as, run this:

crontab -e

Add the line:

@reboot /path/to/your/ServerStart.sh

Save it. That will make it so when the server comes back up after a reboot, it will run your shell script.

This is your crontab, you can learn all about it with man crontab, or the Wikipedia page: https://en.wikipedia.org/wiki/Cron

Here's a easy way to do that using SysVInit. Instructions:

1. Create the start and the stop script of your application. Put it on some directory, in our example is:

   • Start Script: /usr/local/bin/myapp-start.sh
   • Stop Script: /usr/local/bin/myapp-stop.sh

   Each one will provide the instructions to run/stop the app. For instance the myapp-start.sh content can be as simple as the following:

   #!/bin/bash
   
   java -jar myapp.jar 
   

   For the stop script it can be something like this:

   #!/bin/bash
   # Grabs and kill a process from the pidlist that has the word myapp
   
   pid=`ps aux | grep myapp | awk '{print $2}'`
   kill -9 $pid
   

2. Create the following script (myscript) and put it on /etc/init.d.

   /etc/init.d/myscript content:

   #!/bin/bash
   # MyApp
   #
   # description: bla bla
   
   case $1 in
       start)
           /bin/bash /usr/local/bin/myapp-start.sh
       ;;
       stop)
           /bin/bash /usr/local/bin/myapp-stop.sh
       ;;
       restart)
           /bin/bash /usr/local/bin/myapp-stop.sh
           /bin/bash /usr/local/bin/myapp-start.sh
       ;;
   esac
   exit 0
   

3. Put the script to start with the system (using SysV). Just run the following command (as root):

   update-rc.d myscript defaults 
   

PS: I know that Upstart is great and bla bla, but I preffer the old SysV init system.

As a systemd service

(You didn't mention a specific GNU/Linux distribution, I think most common ones have systemd available though)

If you move your .jar file to some accessible place like /opt then you could have systemd run your server after startup as nobody or some other low-privilege user.

In addition to potentially running without access to home directories, etc. you can also configure systemd to restart a service after failure and many other things.

See man systemd.service, man systemd.exec, man systemd.unit, etc.

nukkit.service

[Unit]
Description=Nukkit Server
After=syslog.target
After=network.target

[Service]
Type=simple
User=nobody
Group=nobody
ExecStart=java -jar /opt/Nukkit/nukkit.jar

[Install]
WantedBy=multi-user.target

Watching output

Where you have /etc/systemd/system/nukkit.service and have:

• systemctl enable nukkit
• systemctl start nukkit

then journalctl -f -u nukkit should follow the most recent log messages from systemd unit nukkit. Your system may be using syslog or some other facility though; in that case you could configure logging to a specific file, etc.

You can put your command in file /etc/rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

java -jar file.jar &

exit 0

How about you use the crontab?

As the user you want the jar to run as, run this:

crontab -e

Add the line:

@reboot /path/to/your/ServerStart.sh

Save it. That will make it so when the server comes back up after a reboot, it will run your shell script.

This is your crontab, you can learn all about it with man crontab, or the Wikipedia page: https://en.wikipedia.org/wiki/Cron

Using systemd directives in place of shell results in a more consistent environment. This includes not relying on $PATH or the working directory by providing full paths where they are known.

Neither & for job control, nor managing SIGHUP is needed. systemd service units are already backgrounded.

Assuming the program doesn't fork, in other words the java exec keeps running, that's Type=simple

[Unit]
Description=something

[Service]
ExecStart=/usr/bin/java -jar /var/www/test.com/something.jar
StandardOutput=file:/var/log/something.out.txt
StandardError=file:/var/log/something.err.txt
Type=simple
WorkingDirectory=/var/www/test.com

[Install]
WantedBy=multi-user.target

I think that if you want to run the application as a daemon, the best solution is using Apache Jsvc :

Jsvc is a set of libraries and applications for making Java applications run on UNIX more easily. Jsvc allows the application (e.g. Tomcat) to perform some privileged operations as root (e.g. bind to a port < 1024), and then switch identity to a non-privileged user. It can run on Win32 via the Cygwin emulation layer, however Win32 users may prefer to use procrun instead, which allows the application to run as a Windows Service.

Ideally you should create a service wrapper for your java application and then make this service run on startup example here.

Use
sudo update-rc.d mytestserv defaults to run your service wrapper on startup on Ubuntu

Regrettably, I don't believe there is a single, universal way to accomplish exactly what you want. Each nix has an init system, and there are various different init systems out there (SysV, Upstart, systemd, etc.). Now, systemd has some support for running SysV daemons, so you might be able to get away with writing a SysV script and have it work for both, but I do not know how that will fare with Upstart and other systems. I can see two courses of action that may yet help you accomplish your goal:

1. Write a service for each major init system (note that many distros are switching to systemd, so it may be a good one to start with).

2. Give up on running it at boot and try to run it a little later.

For example, though init systems are still pretty fragmented, shell login is pretty much universal. You could add a couple lines to each $HOME/.shellrc running the jar if it hasn't already been run. Doing so would be much less work and much more universally applicable.

The obvious advantage of 1 is that it would run the jar before users see anything. However, this can be mitigated in 2 by setting up autologin (though not a great idea for security).

Note that, if this is a GUI jar, then you're going to have a fair number of extra headaches (making X, or Wayland start so that your jar can run will add a few lines, at least, to whatever solution you decide).