error code 16 when executing external command to Automic

[MUHAMAD FARHAN ABU BAKAR]

Hello everyone,

I encountered exit code 16 when executing external command to Automic, I tried googling it but didnt found anything helpful, appreciate anyone's help on this.

[Carsten Schmitz]

Hi.

The screenshot is very tightly cropped. It looks like this is a CallAPI process that terminated with return code 16, am I correct with that assumption?

Have you checked the logs, especially the Service Manager log (if you launch that process from Service Manager)?

If this is totally off, please explain in more detail what Automic product and version you use to call what sort of program, and where the fault happens.

Hth,

[MUHAMAD FARHAN ABU BAKAR]

Hello Carsten,

Yes, this is a CallAPI process which is triggered from SAP external command SM69, I dont maintain the login information in the .ini file, but in the command itself.
I don't launch this from service manager, I checked the CP log of automic but it doesn't show much information on the error.

we are using automic version 11. the external command will send a script to automic containing instructions to execute a job. this fault happens after we execute the external command

[Carsten Schmitz]

​Hi.

The SAP CallAPI is a daemonized unix process I think. At least ours is. If you don't start it from the Service Manager, how do you start it? Directly from shell? Any error messages to be found in the controlling shell?

Otherwise, this is a bit of an advanced procedure, but I troubleshot a lot of "exit code something" by using strace. You can attach strace to a running process and tell it to follow all fork() system calls by using:

strace -f -p <pid>

where <pid> is the pid of your CallAPI process. The last syscalls before the error message oftentimes give a clue to the nature of the problem.

Hth,

[MUHAMAD FARHAN ABU BAKAR]

Hi,

We only deploy CallAPi for UNIX and not SAP since we dont call it using ABAP program.
everytime we execute external command, it will call the CallAPI using below command

./ucxblx6c SCRIPT=script.txt LOGON=0001,SMITH,DEV,aerox

my linux knowledge is very limited, since the callapi process runs in only few seconds, may i know how to perform the strace with the PID?

I checked the document on CallAPI and found below information.

[Carsten Schmitz]

​Hi,

> ./ucxblx6c SCRIPT=script.txt LOGON=0001,SMITH,DEV,aerox
> my linux knowledge is very limited, since the callapi process runs in only few seconds,

Okay, I understand now: You are not running the CallAPI as a daemon (the UNIX equivalent of a "service") but you call it every time. You can prefix the command with strace then, such as:

strace ./ucxblx6c SCRIPT=script.txt LOGON=0001,SMITH,DEV,aerox

or, if you don't do it directly from a shell:

strace ./ucxblx6c SCRIPT=script.txt LOGON=0001,SMITH,DEV,aerox > /tmp/strace_output.txt 2>&1

Then look at the output (or /tmp/strace_output.txt), especially towards the end and right before the printing of the "code 16" error message. Look primarily for syscalls that don't return with "0". Sometimes (not always though) the strace output will give you a hint to what's wrong, especially with issues such as wrong file permissions, missing libraries etc.

Not all non-zero syscalls in the output are an error though, sometimes software just does the "trial and error" approach to e.g. opening files. But you can gain hints from the output.

Hope that helps!

[Carsten Schmitz]

​p.s. with that documentation you found, I remember now that "16" is indeed indicative of a problem with file access. So look especially for failing syscalls such as write(). They usually have a number as a parameter, which is a file descriptor. Find the file descriptor in a prior syscall such as open() above in the output to find out what file it tried to write to. Then check the existence of that file or it's permissions.

When checking permissions, it's sometimes best to "su" to the same user that should have access to the file, and navigate to the path where the file is, and try to read or write (whichever is intended) to the file as the same user that runs the process in question. If you look at the file permissions exclusively, one may sometimes miss a lack of permissions somewhere up in the directory structure, so always try to diagnose permission issues as the actual user, if possible.

Hth,

[MUHAMAD FARHAN ABU BAKAR]

Hi,

I did the strace step as below, and we managed to fix the error based on the log, after that the execution was successful.

However, when I removed the strace, the execution kept failing again.

 do you have any idea why execution with strace always successful but without it doesn't?

Thanks & Regards,
Farhan.