[2.0.5] Linux: ssh: command line scriptrun: intermittently Getting a return code of 1 when expecting 0

Bug #1948708 reported by Devin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SikuliX
In Progress
Medium
RaiMan

Bug Description

Hello,

We're using:
sikulixide-2.0.5.jar
Ubuntu 20.04.3 LTS, x86_64
openjdk version "14.0.2" 2020-07-14

We have code similar to the following that we're running in Linux (Ubuntu 20.04) via bash:
----------------------------------------------
  echo "Testing $d"
  export DISPLAY=:0 && java -jar $TEST_PATH/../../sikulixide-2.0.5.jar -r $d

  # Store return code from the Sikuli script before running any other commands.
  RESULT=$?

  EPOCH=$(date +%s)

  # check the return code of the Sikuli script and exit with 1 if it failed
  if [ $RESULT -ne 0 ]; then
     echo "The result code from the failed test was $RESULT."
     echo "__TEST_RESULT__: $EPOCH, FAILED"
     exit 1
  else
     echo "__TEST_RESULT__: $EPOCH, PASSED"
  fi
----------------------------------------------

We're running these Sikuli scripts on Windows, macOS, and Linux. Only the Linux ones are giving us this issue. Also, this is only seen intermittently on Linux.

We're running them over SSH, hence the "export DISPLAY=:0". The system is a laptop that has its internal LCD left on all the time.

We originally had our scripts just "run to completion" to get a return code of 0. However, due to this issue we tried Python's "sys.exit(0)" and also Sikuli's "exit(0)". However, we're still having this issue intermittently.

Usually the scripts exit and return 0 as expected. However, lately we've been having an issue where the scripts will fail with a return code of 1 even though they reach the end (or even use exit(0) a the end).

For example:
----------------------------------------------
"[info (2021-10-25, 1:44:16 p.m.)] Exit code: 0
The result code from the failed test was 1.
__TEST_RESULT__: 1635183856, FAILED
----------------------------------------------

How can Sikuli use exit(0) but have a return code of 1? Is there another way to have a Sikuli script return a 0 code on exit?

As a work around, we might instead log the output from Sikuli to a file and then grep it for "Exit code: 0" to check if it passed instead of checking the return code. My preference would be to check the return code instead though.

Is there something wrong with our bash code that stores the Sikuli return code? Or is it a bug in Linux/Sikuli that's causing it to return the wrong return code (1 instead of 0)?

Thanks,
Devin

RaiMan (raimund-hocke)
Changed in sikuli:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → RaiMan (raimund-hocke)
milestone: none → 2.0.6
summary: - Getting a return code of 1 in Linux when I'm expecting 0
+ [2.0.5] Linux: ssh: command line scripture: intermittently Getting a
+ return code of 1 when expecting 0
summary: - [2.0.5] Linux: ssh: command line scripture: intermittently Getting a
+ [2.0.5] Linux: ssh: command line scriptrun: intermittently Getting a
return code of 1 when expecting 0
Revision history for this message
RaiMan (raimund-hocke) wrote :

Looking into the script run implementation, a non-intentionally exit code 1 is only produced, if the the Jython script run exits with an exception, that is happening outside the script, hence something in the area ssh-Java-Jython.
Internally the cause is saved, but not logged and not reported to the outside (which is something to be enhanced ;-)

So currently I cannot help you.

You might check with the latest Java 17 (which is an LTS version) and try to watch the environment of the script run about differences, when exit code is 1.

If no success, then you have to implement a workaround like this:
- touch some file
- in the script delete the file on exit(0)
- on command line check the file exists or not if exit code is 1
... so no need to handle file content additionally

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.