B4J Question Executable path is not absolute

[aaronk]

Hi,

I have a VPS, and trying to work out the full location of the files so I can create a service so my B4J app runs on system start up (in case my service reboots).

I have used SFTP and copied the files to my VPS and now trying to run them but I need to work out the full location to where they were copied to.

In the navigation up the top (in the image below) it shows /root/Java
Is that the full location of my files ?

My script shows:
(I have been following this tutorial: https://www.b4x.com/android/forum/t...ice-and-automatically-starting-at-boot.85739/)

I then run: sudo systemctl enable CloudServer.service
(got no reply other than allowing me to type another command)

Then I used: sudo systemctl start CloudServer.service

However that shows an error.

Running systemctl status CloudServer.service it shows:

● CloudServer.service - CloudServer Service
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)

Mar 31 17:41:06 rubber-global systemd[1]: [/etc/systemd/system/CloudServer.service:7] Executable path is not absolute, ignoring: ~/Java/bin/ -jar ~/CloudServer/CloudServer.jar
Mar 31 17:41:06 rubber-global systemd[1]: CloudServer.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Mar 31 17:46:25 rubber-global systemd[1]: [/etc/systemd/system/CloudServer.service:7] Executable path specifies a directory, ignoring: /Java/bin/ -jar /CloudServer/CloudServer.j
Mar 31 17:46:25 rubber-global systemd[1]: CloudServer.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Mar 31 17:48:23 rubber-global systemd[1]: [/etc/systemd/system/CloudServer.service:7] Executable path specifies a directory, ignoring: /root/Java/bin/ -jar /root/CloudServer/Clo
Mar 31 17:48:23 rubber-global systemd[1]: CloudServer.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Mar 31 18:19:36 rubber-global systemd[1]: [/etc/systemd/system/CloudServer.service:7] Executable path specifies a directory, ignoring: /root/Java/bin/ -jar /root/CloudServer/Clo
Mar 31 18:19:36 rubber-global systemd[1]: CloudServer.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
lines 1-12/12 (END)

Am I doing this correct or do I have the path wrong, or is there something else ?

 

[udg]

Hi @aaronk ,

I'm using the following to start a service of mine:

[Service]
Type=simple
ExecStart=/usr/bin/java -Xmx256m -jar /opt/udgapps/varius/varsvc1.jar
TimeoutStartSec=0
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

Main difference with your code is in ExecStart where I list the "java" command too while you stop at its folder.
This is on a CentOs 7 (never used this distro before so I've often to search for commands..)

ps: wish I read @Ed Brown 's post you cited weeks ago, sparing me some good time.

 

[aaronk]

I'm using the following to start a service of mine:

What does -Xmx256m do ?

I have now made a small adjustment to my script:

sudo nano /etc/systemd/system/CloudServer.service

[Unit]
Description=CloudServer Service
After=network.target

[Service]
Type=simple
ExecStart=/root/Java -jar /root/CloudServer/CloudServer.jar

SuccessExitStatus=143

Restart=on-abort

[Install]
WantedBy=multi-user.target

Seems that I don't have to include /bin in the ExecStart for the Java part.

Normally I would use: nohup path_to_java/bin/java -jar somejar.jar > nohup.out &

And that would write the log to a file. Is there a way in doing this with the service script ?

 

[udg]

What does -Xmx256m do ?

Maximun Heap Memory for the JVM set to 256MB

Normally I would use: nohup path_to_java/bin/java -jar somejar.jar > nohup.out &

If that works than you should use "path_to_java/bin/java" in your service too; in my case it is "/usr/bin/java", in other words, the full path to the executable java.

I'm not a Linux expert. What I did was just read a few docs on the Internet and adapt them to my needs (so I'm not 100% sure that my solution is complete and/or correct).
If you get the same "invalid argument" when you try to start your service than you should understand what's wrong in it before attempting the "enable" command.
My guess is that java or your CloudServer.jar are unreachable from the script.

Note: I read that (in CentOS) the preferred place to upload our apps is /opt rather than /root . Anyway I would investigate on why you have java installed in /root .

 

[aaronk]

Anyway I would investigate on why you have java installed in /root

When I connected with SFTP it was the first directory it loaded so I thought it would be as good as any to use.

If that works than you should use "path_to_java/bin/java" in your service too

I copied that text from one of Erel's tutorials. Just using it as an example.

All my files are in:
/root/Java
/root/CloudServer/CloudServer.jar

Here is what I have done and I think it kind of worked but I think there is now another issue..

sudo nano /etc/systemd/system/CloudServer.service

Entered in:

[Unit]
Description=CloudServer Service
After=network.target

[Service]
Type=simple
ExecStart=/root/Java -jar /root/CloudServer/CloudServer.jar

SuccessExitStatus=143

Restart=on-abort

[Install]
WantedBy=multi-user.target

Saved it.

sudo systemctl enable CloudServer.service

Replies with:
Created symlink from /etc/systemd/system/multi-user.target.wants/CloudServer.service to /etc/systemd/system/CloudServer.service.

sudo systemctl start CloudServer.service

CloudServer.service - CloudServer Service
Loaded: loaded (/etc/systemd/system/CloudServer.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2018-03-31 20:50:56 AEDT; 4min 39s ago
Process: 11473 ExecStart=/root/Java -jar /root/CloudServer/CloudServer.jar (code=exited, status=203/EXEC)
Main PID: 11473 (code=exited, status=203/EXEC)

Mar 31 20:50:56 rubber-global systemd[1]: Started CloudServer Service.
Mar 31 20:50:56 rubber-global systemd[1]: CloudServer.service: Main process exited, code=exited, status=203/EXEC
Mar 31 20:50:56 rubber-global systemd[1]: CloudServer.service: Unit entered failed state.
Mar 31 20:50:56 rubber-global systemd[1]: CloudServer.service: Failed with result 'exit-code'.

I think it ran but then stopped ?

 

[udg]

I don't know if it could be related, but did you set execute permission on it?
Edit: sorry, it's not your/our case. That applies when the java app is launched from a script and we execute that script from the service (it was my original attempt).

 

[aaronk]

I don't know if it could be related, but did you set execute permission on it?

I am only new at this.. I guess not since I am unsure what you mean by that.

Does your script that you posted (in post 2) does that run when the server is powered up or do you need to manually run it after the server boots up ?

(I have now moved my Java files to the same location as your one, and moved my .jar file to /opt now, and will run your script and see how I go.)

 

[aaronk]

did you set execute permission on it?

I think this might be the issue.

I copied the files to:
/usr/bin/java
/opt/CloudServer/CloudServer.jar

Using the following script:

[Service]
Type=simple
ExecStart=/usr/bin/java -jar /opt/CloudServer/CloudServer.jar
TimeoutStartSec=0
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

systemctl status CloudServer.service

When I run that it shows:

● CloudServer.service
Loaded: loaded (/etc/systemd/system/CloudServer.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Sat 2018-03-31 21:58:58 AEDT; 1s ago
Process: 2678 ExecStart=/usr/bin/java -jar /opt/CloudServer/CloudServer.jar (code=exited, status=203/EXEC)
Main PID: 2678 (code=exited, status=203/EXEC)

Mar 31 21:58:58 rubber-global systemd[1]: CloudServer.service: Main process exited, code=exited, status=203/EXEC
Mar 31 21:58:58 rubber-global systemd[1]: CloudServer.service: Unit entered failed state.
Mar 31 21:58:58 rubber-global systemd[1]: CloudServer.service: Failed with result 'exit-code'.

If I run:

nohup /usr/bin/java -jar /opt/CloudServer/CloudServer.jar > nohup.out &

It returns:
nohup: ignoring input and redirecting stderr to stdout
nohup: failed to run command '/usr/bin/java': Permission denied

 

[udg]

My /usr/bin/java has -rwxrwxrwx as its permissions, while my /opt/udgapps/varius/varsvc1.jar has -rw-r--r--

Note: I was lazy and acted as root all the time. A better way is to activate a new user, assign needed permissions, log with that user and "sudo" when needed.

Does your script that you posted (in post 2) does that run when the server is powered up or do you need to manually run it after the server boots up ?

I used the service stuff because I wanted it launched at boot. First time I launched it manually with the "start" command in order to verify that non errors where raised.

nohup: failed to run command '/usr/bin/java': Permission denied

Check your java permissions.

 

[aaronk]

I got it to work.

For anyone else with the same issue here is how I got it to work..

I used SFTP and copied my B4J app to /opt/CloudServer/CloudServer.jar

I only copied the B4J files only.

For some reason even knowing I copied the Java files using SFTP (in the above posts), it didn't work, so I deleted the Java files before running the following:

I ran:
apt-get install default-jdk
(This installed Java on my server.)

Then:
add-apt-repository ppa:webupd8team/java

I then ran:
java -version
This told me what version of Java was installed. If it returns a value then you will know Java is setup and working.

I then created a start-up script. This script will run as soon as the server boots up.

sudo nano /etc/systemd/system/CloudServer.service

[Unit]
Description=CloudServer Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/java -jar /opt/CloudServer/CloudServer.jar

SuccessExitStatus=143

Restart=on-abort

[Install]
WantedBy=multi-user.target

sudo systemctl enable CloudServer.service
This will enable the service.

sudo systemctl start CloudServer.service
This will start the service.

systemctl status CloudServer.service
This will check the service.