Ignition version 7.6.4 (clientlauncher is also 7.6.4)
Ubuntu version 12.04.2 LTS
If I run ./clientlauncher.sh from Terminal, then choose the Project and keep checkbox enabled for Create Shortcut, the project launches fine. However, the newly created shortcut doesn’t work. I changed the Command by typing the prefix “gnome-terminal -e” but that only changed the error window to show up in Terminal vs the Popup. Also tried chmod +x to both clientlauncher.sh and the Desktop Shortcut. Also enabled Scripts to run as executable in Nautilus.
[attachment=1]client_launcher1.png[/attachment]
Here is line 126 that it seems to be complaining about.
[attachment=0]client_launcher3.png[/attachment]
I also tried clientlauncher 7.6.5-rc1 and had the same issue.
I’m sure this is something with Ubuntu and security or something with Desktop Shortcuts, but I just can’t figure it out.
Are you just trying to launch a client from the terminal? In that case, you don’t need to use the desktop shortcut at all. Just execute clientlauncher.sh in the terminal like so:
Launching via the Terminal works fine. The problem is the machine operators aren’t very good at typing commands and we were hoping to launch from the shortcut that the clientlauncher creates on the Desktop.
The script is acting like it can’t find Java when it launches from the shortcut. The first error occurs because the Java version cannot be retrieved. Can you run “java -version” from the Terminal without issues? Maybe also try setting a JAVA_HOME environment variable to your Java installation. The script first looks for Java in the system path and then checks whether the JAVA_HOME variable is set. Also, if the only place where a Java installation is referenced is in a place like .bashrc, then maybe items that don’t run a terminal (such as a desktop shortcut) may not be able to locate the Java installation.
Thanks for the follow up. I also thought the problem was that the Shortcut couldn’t locate the Java installation, so I tried the following in every file I could think of (~/.profile, ~/.bashrc, /etc/profile, /etc/environment, /etc/bash.bashrc)
How about this: I have compiled clientlauncher.sh with echo statements that echo to test.log when some of those functions are called. It is available here. When clientlauncher.sh runs, it will echo variables to test.log. I still can’t find any reason why only a desktop shortcut cannot locate Java. FWIW, I have Ubuntu 12.04 64-bit running in a VM here with OpenJDK 1.7.0_51, and it is able to launch desktop shortcuts without issues. So try the script and post your output from test.log.
I did some more testing as well. We can take the shortcut out of the equation because I’m able to reproduce the condition via the Terminal by running clientlauncher.sh with a folder in front of it. Example:
it@BGM-DBESCY009645:~/ignition_clientlauncher$ ./clientlauncher.sh scope=C project=projectName gateway.addr=x.x.x.x:8088/main windowmode=fullscreen works fine (working.log)
it@BGM-DBESCY009645:~$ ignition_clientlauncher/clientlauncher.sh scope=C project=projectName gateway.addr=x.x.x.x:8088/main windowmode=fullscreen causes the problem (broken.log)
Here are the results of the echoed output:
WORKING.LOG
getjavaversion(): Using java '/usr/local/java/jre1.7.0_51', version is ./clientlauncher.sh: line 541: /usr/local/java/jre1.7.0_51: Is a directory
checkextra(): Running for './clientlauncher.sh:'
checkextra(): Found './clientlauncher.sh:_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for './clientlauncher.sh:_'
extractvn(): Successfully extracted version ''
extractvn(): Extracting version for '1.6.0_'
extractvn(): Successfully extracted version '1'
getjavaversion(): Using java 'java', version is java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)
checkextra(): Running for '1.7.0_51'
checkextra(): Found '1.7.0_51_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for '1.7.0_51_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '1.6.0_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '7.0_51_'
extractvn(): Successfully extracted version '7'
extractvn(): Extracting version for '6.0_'
extractvn(): Successfully extracted version '6'
BROKEN.LOG
getjavaversion(): Using java '/usr/local/java/jre1.7.0_51', version is ignition_clientlauncher/clientlauncher.sh: line 541: /usr/local/java/jre1.7.0_51: Is a directory
checkextra(): Running for 'ignition_clientlauncher/clientlauncher.sh:'
checkextra(): Found 'ignition_clientlauncher/clientlauncher.sh:_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for 'ignition_clientlauncher/clientlauncher.sh:_'
extractvn(): Successfully extracted version 'ignition_clientlauncher/clientlauncher'
getjavaversion(): Using java '/usr/local/java/jre1.7.0_51/bin/java', version is java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)
checkextra(): Running for '1.7.0_51'
checkextra(): Found '1.7.0_51_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for '1.7.0_51_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '1.6.0_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '7.0_51_'
extractvn(): Successfully extracted version '7'
extractvn(): Extracting version for '6.0_'
extractvn(): Successfully extracted version '6'
getjavaversion(): Using java '/var/lib/dpkg/alternatives/java', version is ignition_clientlauncher/clientlauncher.sh: line 541: /var/lib/dpkg/alternatives/java: Permission denied
checkextra(): Running for 'ignition_clientlauncher/clientlauncher.sh:'
checkextra(): Found 'ignition_clientlauncher/clientlauncher.sh:_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for 'ignition_clientlauncher/clientlauncher.sh:_'
extractvn(): Successfully extracted version 'ignition_clientlauncher/clientlauncher'
Not sure if the “Permission denied” has anything to do with it, but I did notice that line being different.
I’m also not sure why or how it’s detecting 1.6.0. I removed everything I could think of and purged all the OpenJDK and IceTea stuff before replacing with Oracle Java 1.7.0.51.
By the way, thanks for going the extra mile with me on this one…recompiling with debug output…you guys are great!
Spent some more time researching this today. It appears that what is happening in your case is that the clientlauncher.sh script is taking in your JAVA_HOME (set to /usr/local/java/jre1.7.0_51) and trying to run “java -version” on it. The problem is that /usr/local/java/jre1.7.0_51 is a directory and not the java executable, and running the command returns an error. The script thinks that the error text is a version, and thus chokes when trying to call “declare -i” (which expects a number). I am still at a loss to explain why this doesn’t work with desktop shortcuts, but I did find that you have to run clientlaunch.sh from within its folder, or by an absolute path. Calling it from outside its folder results in other errors. This is why the desktop shortcuts are supposed to have a full path to clientlauncher.sh. There are two things that you can try. First, change JAVA_HOME to add /bin/java to the end of the path. So your JAVA_HOME might look like this:/usr/local/java/jre1.7.0_51/bin/java The other thing you can try is to append this argument to the end of a desktop shortcut: --jnixoptpath=\"/usr/local/java/jre1.7.0_51/bin/java\"
Here’s the test.log after the change if you’re interested:
getjavaversion(): Using java '/usr/local/java/jre1.7.0_51/bin/java', version is java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Server VM (build 24.51-b03, mixed mode)
checkextra(): Running for '1.7.0_51'
checkextra(): Found '1.7.0_51_'
checkextra(): Running for '1.6.0'
checkextra(): Found '1.6.0_'
extractvn(): Extracting version for '1.7.0_51_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '1.6.0_'
extractvn(): Successfully extracted version '1'
extractvn(): Extracting version for '7.0_51_'
extractvn(): Successfully extracted version '7'
extractvn(): Extracting version for '6.0_'
extractvn(): Successfully extracted version '6'
The Desktop Shortcut is working and all is well! Thanks so much for your help.
On a side note, what command/function is that script calling that finds the old 1.6.0 OpenJDK version? I’m trying to clean up the system and can’t find that referenced anywhere with ‘locate java’ or any of the ‘alternatives’ commands.
Success! The 1.6.0 that you are seeing in the log is actually the minimum Java version required to run the client launcher. It’s a setting that we set in a config file before everything gets compiled. Apparently the script uses the same functions to parse both the minimum version and the Java versions that were found on your machine.
