4

The following script is an entrypoint to a docker image.

run.sh

#!/bin/bash

# wrapper function for docker entrypoint, allows:
# docker run -> runs the service
# docker run test -> runs the tests

set -e

export CLI='src/cli.py'

if [[ "$1" == "test"* ]]; then
    py.test tests
    exit $?
elif [[ "$1" == "junit"* ]]; then
    mkdir -p /junit
    py.test --junitxml=/junit/test-results.xml tests
    exit $?
fi;

python3 -u "$CLI" "$BACKEND"

What does this error mean?

./run.sh: line 20:     5 Illegal instruction     python3 -u "$CLI" "$BACKEND"

The container is up and running so I guess it fails sometimes, gets restarted and then works.

dimo414
  • 47,227
  • 18
  • 148
  • 244
kev
  • 8,928
  • 14
  • 61
  • 103
  • I think that semicolon in the end of the `fi` line can be removed. Have you ever tried doing that? Also, it could be a good idea to use the full path of the python3 binary, i.e., something like `/usr/local/bin/python3` (You have to run `which python3` in order to find out where you python3 binary is). – Rod Elias Mar 21 '18 at 00:32
  • 3
    It means `python3` is actually crashing because it contains an instruction unsuited to the CPU you're running on. – paxdiablo Mar 21 '18 at 00:45
  • @paxdiablo any idea how I could track down the issue? – kev Mar 21 '18 at 00:46
  • 1
    Not really, my experience with Docker is limited. It *may* be something VM-ish in that python3 is running some privileged instruction that Docker does not support but I couldn't say for sure. – paxdiablo Mar 21 '18 at 00:47
  • What happens if you run line 20 by hand? Do you get a core dump if you run `ulimit -c unlimited` first? What happens if you run it outside a container? – Attie Mar 21 '18 at 08:20
  • 1
    That's not from bash, it's from Python. You'd get the same error if you ran the same command in any other way, including ways that don't involve any shell at all. – Charles Duffy Mar 28 '18 at 16:03
  • Post your Python code. Is there no stack? – kabanus Mar 28 '18 at 16:04
  • @kabanus, ...more likely it's an interpreter built for a different CPU -- not a whole different architecture, but optimized to use extensions the current CPU doesn't have. You might be able to pin down a C module, but I that's iffy. – Charles Duffy Mar 28 '18 at 16:04
  • Do you want a globbing shell, here: `[[ "$1" == "junit"* ]]; ` – wildplasser Mar 28 '18 at 16:05
  • 1
    @wildplasser, inside `[[ ]]` in bash or ksh, that isn't a glob, it's a fnmatch-style test. It's correct code, equivalent to `case $1 in "junit"*) ...;; esac` in baseline POSIX shells. – Charles Duffy Mar 28 '18 at 16:06
  • @CharlesDuffy that's a good point, didn't think about that. kev, which Python? 32/64 bit mismatch perhaps? – kabanus Mar 28 '18 at 16:06
  • @CharlesDuffy Aha, I see. – wildplasser Mar 28 '18 at 16:07
  • I wonder if maybe the OP is using a library like scipy that will use modern SSE instructions if/when they're available. – Charles Duffy Mar 28 '18 at 16:08
  • @kabanus, ...in *theory*, a 32/64-bit mismatch should stop the executable from being linked and loaded, rather than failing later at execution time. While it's possible for practice to diverge, I'd be much less surprised by, say, code compiled to use SSE4.2 instructions running on a CPU that only provides SSE4.1. – Charles Duffy Mar 28 '18 at 16:09
  • @CharlesDuffy On Linux flavors it will complain it can't run, I wonder if there may be some esoteric flavor with a different error? – kabanus Mar 28 '18 at 16:12
  • A simpler guess would be a corrupt Python - OP, maybe try to download again? – kabanus Mar 28 '18 at 16:14
  • Anyhow, if we really wanted to track it down, the place to start is with a debugger -- attach gdb to the Python interpreter run and you can get a stack trace inside the interpreter, and thereby figure out if it's happening in the interpreter core, in a C library it's loading, etc. – Charles Duffy Mar 28 '18 at 16:15
  • ...btw, as an aside, `exit $?` is redundant -- `exit` always exits with the status of the most recent command, `$?`, by default. (Also, all-caps names are used for variables meaning to the shell or POSIX-defined tools, whereas lowercase names are reserved for application use -- see [relevant POSIX spec](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html), fourth paragraph). And consider making a habit of using `=` rather than `==` -- only the former is allowed in POSIX `test`, so using the latter can lead to finger memory that misleads when writing for other shells. – Charles Duffy Mar 28 '18 at 16:23

0 Answers0