Why does system() fail with error code 127?
On a Linux system I am trying to call a program at runtime with the system() call. The system call exits with an return code not equal zero. Calling WEXITSTATUS on the error code gives «127». According to the man page of system this code indicates that /bin/sh could not be called: In case /bin/sh could not be executed, the exit status will be that of a command that does exit(127) . I checked: /bin/sh is a link to bash . bash is there. I can execute it from the shell. Now, how can I find out why /bin/sh could not be called ? Any kernel history or something? Edit: After the very helpful tip (see below) i strace -f -p
Process 16080 detached [pid 11779] ) = ? ERESTARTNOHAND (To be restarted) [pid 11774] [], 0, NULL) = 16080 [pid 11779] --- SIGCHLD (Child exited) @ 0 (0) --- [pid 11779] rt_sigaction(SIGCHLD, , [pid 11774] rt_sigaction(SIGINT, , [pid 11779] , 8) = 0 [pid 11779] sendto(5, "a", 1, 0, NULL, 0 [pid 11774] NULL, 8) = 0 [pid 11779] ) = 1 [pid 11779] rt_sigreturn(0x2 [pid 11774] rt_sigaction(SIGQUIT, , [pid 11779] ) = -1 EINTR (Interrupted system call) [pid 11779] select(16, [9 15], [], NULL, NULL [pid 11774] NULL, 8) = 0 [pid 11774] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 [pid 11774] write(1, "Problems calling nvcc jitter: ex". 49) = 49 [pid 11774] rt_sigaction(SIGINT, , , 8) = 0 [pid 11774] rt_sigaction(SIGQUIT, , , 8) = 0 [pid 11774] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 [pid 11774] clone(Process 16081 attached (waiting for parent) Process 16081 resumed (parent 11774 ready) child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7fff0177ab68) = 16081 [pid 16081] rt_sigaction(SIGINT, , [pid 11774] wait4(16081, Process 11774 suspended [pid 16081] NULL, 8) = 0 [pid 16081] rt_sigaction(SIGQUIT, , NULL, 8) = 0 [pid 16081] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 [pid 16081] execve("/bin/sh", ["sh", "-c", 0xdda1d98], [/* 58 vars */]) = -1 EFAULT (Bad address) [pid 16081] exit_group(127) = ? Process 11774 resumed When it comes to the call to /bin/sh it says bad address. Why that ? Edit: Here the whole part that involves the failing system (here already the safe copy to a buffer is in place):
std::ostringstream jit_command; jit_command else if (WIFSIGNALED(ret)) < printf("killed by signal %d\n", WTERMSIG(ret)); >else if (WIFSTOPPED(ret)) < printf("stopped by signal %d\n", WSTOPSIG(ret)); >else if (WIFCONTINUED(ret)) < printf("continued\n"); >else < printf("not recognized\n"); >cout delete[] cmd; return true; /usr/local/cuda/bin/nvcc -v --ptxas-options=-v -arch=sm_20 -m64 --compiler-options -fPIC,-shared -link bench_cudp_Oku2fm.cu -I$LIB_PATH/include -o bench_cudp_Oku2fm.o Problems calling nvcc jitter: exited, status=127 Checking shell.. ok! string gen = jit_command.str(); cout The complexity of the string creation is not the problem here. As strace shows a "bad address" is the problem. Its a legal string. A "bad address" should not occur. As far as i know the std::string::c_str() returns a const char * that might point to a scratch space of libc++ where a read only copy of the string might be kept. Unfortunately the error is not really reproduceable. The call to system succeeds several times before it fails. I don't want to be hasty but it smells like a bug in either in the kernel, libc or the hardware. Edit: I produced a more verbose strace output ( strace -f -v -s 2048 -e trace=process -p $! ) of the failing execve system call: First a succeeding call:
[pid 2506] execve("/bin/sh", ["sh", "-c", "/usr/local/cuda/bin/nvcc -v --ptxas-options=-v -arch=sm_20 -m64 --compiler-options -fPIC,-shared -link /home/user/toolchain/kernels-empty/bench_cudp_U11PSy.cu -I$LIB_PATH/include -o /home/user/toolchain/kernels-empty/bench_cudp_U11PSy.o"], ["MODULE_VERSION_STACK=3.2.8", . ]) = 0 [pid 17398] execve("/bin/sh", ["sh", "-c", 0x14595af0], ) = -1 EFAULT (Bad address) Here is identical. It seems its not the list of environment variables that cause the bad address. As Chris Dodd mentioned the 3rd argument to execve is the raw pointer 0x14595af0, which strace thinks (and the kernel agrees) is invalid. strace does not recognize it as a string (so it prints the hex value and not the string). Edit: I inserted print out of the pointer value cmd to see what's the value of this pointer in the parent process:
string gen = jit_command.str(); cout cmd = 0x14595af0 failed cmd = 0x14595af0 Problems calling nvcc jitter: exited, status=127 Checking shell.. ok! Its the same pointer value as the 3rd argument from strace . (I updated the strace output above). Regards the 32bit looking of the cmd pointer: I checked the value of the cmd pointer for a succeeding call. Can't see any difference in structure. That's one of the values of cmd when then system call succeeds:
Meanwhile let me post a workaround. Its so silly to be forced to implement something like that. but it works. So the following code block gets executed in case the system call fails. It allocates new command strings and retries until it succeeds (well not indefinitely).
list listPtr; int maxtry=1000; do < char* tmp = new(nothrow) char[gen.size()+1]; if (!tmp) __error_exit("no memory for jitter command"); strcpy(tmp,gen.c_str()); listPtr.push_back( tmp ); >while ((ret=system(listPtr.back())) && (--maxtry>0)); while(listPtr.size()) I just saw that this workaround in one particular run did not work. It went the whole way, 1000 attempts, all with newly allocated cmd command strings. All 1000 failed. Not only this. I tried on a different Linux host (same Linux/software configuration tho).
Taking this into account one would maybe exclude a hardware problem. (Must be on 2 physically different hosts then). Remains a kernel bug ??
torek, i will try and install a modified system call. Give me some time for that.
Linux код возврата 127
Таблица C-1. "Зарезервированные" коды завершения
| Код завершения | Смысл | Пример | Примечание |
|---|---|---|---|
| 1 | разнообразные ошибки | let "var1 = 1/0" | различные ошибки, такие как "деление на ноль" и пр. |
| 2 | согласно документации к Bash -- неверное использование встроенных команд | Встречаются довольно редко, обычно код завершения возвращается равным 1 | |
| 126 | вызываемая команда не может быть выполнена | возникает из-за проблем с правами доступа или когда вызван на исполнение неисполняемый файл | |
| 127 | "команда не найдена" | Проблема связана либо с переменной окружения $PATH, либо с неверным написанием имени команды | |
| 128 | неверный аргумент команды exit | exit 3.14159 | команда exit может принимать только целочисленные значения, в диапазоне 0 - 255 |
| 128+n | фатальная ошибка по сигналу "n" | kill -9 $PPID сценария | $? вернет 137 (128 + 9) |
| 130 | завершение по Control-C | Control-C -- это выход по сигналу 2, (130 = 128 + 2, см. выше) | |
| 255* | код завершения вне допустимого диапазона | exit -1 | exit может принимать только целочисленные значения, в диапазоне 0 - 255 |
Согласно этой таблице, коды завершения 1 - 2, 126 - 165 и 255 [1] имеют предопределенное значение, поэтому вам следует избегать употребления этих кодов для своих нужд. Завершение сценария с кодом возврата exit 127, может привести в замешательство при поиске ошибок в сценарии (действительно ли он означает ошибку "команда не найдена" ? Или это предусмотренный программистом код завершения?). В большинстве случаев, программисты вставляют exit 1, в качестве реакции на ошибку. Так как код завершения 1 подразумевает целый "букет" ошибок, то в данном случае трудно говорить о какой либо двусмысленности, хотя и об информативности -- тоже.
Не раз предпринимались попытки систематизировать коды завершения (см. /usr/include/sysexits.h), но эта систематизация предназначена для программистов, пишущих на языках C и C++. Автор документа предлагает ограничить коды завершения, определяемые пользователем, диапазоном 64 - 113 (и, само собой разумеется -- 0, для обозначения успешного завершения), в соответствии со стандартом C/C++. Это сделало бы поиск ошибок более простым.
Обращение к переменной $?, из командной строки, после завершения работы сценария, дает результат, в соответствии с таблицей, приведенной выше, но только для Bash или sh . Под управлением csh или tcsh значения могут в некоторых случаях отличаться.
Примечания
Указание кода завершения за пределами установленного диапазона, приводит к возврату ошибочных кодов. Например, exit 3809 вернет код завершения, равный 225 .
Популярный Linux
Приложение D. Коды завершения, имеющие предопределенный смысл
Таблица D-1. "Зарезервированные" коды завершения
| Код завершения | Смысл | Пример | Примечание |
|---|---|---|---|
| 1 | разнообразные ошибки | let "var1 = 1/0" | различные ошибки, такие как "деление на ноль" и пр. |
| 2 | согласно документации к Bash — неверное использование встроенных команд | Встречаются довольно редко, обычно код завершения возвращается равным 1 | |
| 126 | вызываемая команда не может быть выполнена | возникает из-за проблем с правами доступа или когда вызван на исполнение неисполняемый файл | |
| 127 | "команда не найдена" | Проблема связана либо с переменной окружения $PATH, либо с неверным написанием имени команды | |
| 128 | неверный аргумент команды exit | exit 3.14159 | команда exit может принимать только целочисленные значения, в диапазоне 0 - 255 |
| 128+n | фатальная ошибка по сигналу "n" | kill -9 $PPID сценария | $? вернет 137 (128 + 9) |
| 130 | завершение по Control-C | Control-C — это выход по сигналу 2, (130 = 128 + 2, см. выше) | |
| 255* | код завершения вне допустимого диапазона | exit -1 | exit может принимать только целочисленные значения, в диапазоне 0 - 255 |
Согласно этой таблице, коды завершения 1 - 2, 126 - 165 и 255 [67] имеют предопределенное значение, поэтому вам следует избегать употребления этих кодов для своих нужд. Завершение сценария с кодом возврата exit 127, может привести в замешательство при поиске ошибок в сценарии (действительно ли он означает ошибку "команда не найдена" ? Или это предусмотренный программистом код завершения?). В большинстве случаев, программисты вставляют exit 1, в качестве реакции на ошибку. Так как код завершения 1 подразумевает целый "букет" ошибок, то в данном случае трудно говорить о какой либо двусмысленности, хотя и об информативности — тоже.
Не раз предпринимались попытки систематизировать коды завершения (см. /usr/include/sysexits.h), но эта систематизация предназначена для программистов, пишущих на языках C и C++. Автор документа предлагает ограничить коды завершения, определяемые пользователем, диапазоном 64 - 113 (и, само собой разумеется — 0, для обозначения успешного завершения), в соответствии со стандартом C/C++. Это сделало бы поиск ошибок более простым.
Все сценарии, прилагаемые к данному документу, приведены в соответствие с этим стандартом, за исключением случаев, когда существуют отменяющие обстоятельства, например в Пример 9-2.
Обращение к переменной $?, из командной строки, после завершения работы сценария, дает результат, в соответствии с таблицей, приведенной выше, но только для Bash или sh . Под управлением csh или tcsh значения могут в некоторых случаях отличаться.
[67] Указание кода завершения за пределами установленного диапазона, приводит к возврату ошибочных кодов. Например, exit 3809 вернет код завершения, равный 225 .
How to fix exit status 127?
I attempted to follow this guide to run a Node application as a service. However, it is failing to start, with exit code 127. Is there any way to fix this? This is the journal.
sudo journalctl --follow -u serviceName -- Logs begin at Tue 2017-08-08 16:27:10 GMT. -- Aug 08 17:06:57 raspberrypi systemd[1]: Started serviceName. Aug 08 17:06:57 raspberrypi app.js[7234]: [46B blob data] Aug 08 17:06:57 raspberrypi systemd[1]: serviceName.service: main process exited, code=exited, status=127/n/a Aug 08 17:06:57 raspberrypi systemd[1]: Unit serviceName.service entered failed state. Aug 08 17:06:57 raspberrypi systemd[1]: serviceName.service holdoff time over, scheduling restart. Aug 08 17:06:57 raspberrypi systemd[1]: Stopping serviceName. Aug 08 17:06:57 raspberrypi systemd[1]: Starting serviceName. Aug 08 17:06:57 raspberrypi systemd[1]: serviceName.service start request repeated too quickly, refusing to start. Aug 08 17:06:57 raspberrypi systemd[1]: Failed to start serviceName. Aug 08 17:06:57 raspberrypi systemd[1]: Unit serviceName.service entered failed state. [Unit] Description=ServiceName After=network.target [Service] ExecStart=/home/pi/projects/ServiceName/app.js Restart=always User=root Group=root Environment=PATH=/usr/bin:/usr/local/bin Environment=NODE_ENV=production WorkingDirectory=/home/pi/projects/ServiceName [Install] WantedBy=multi-user.target 1. node is /home/pi/.nvm/versions/node/v7.8.0/bin/node 2. Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 6166268 4446224 1383764 77% /