Potentially issues with "system" command (Nuby)

[Thomas Luedeke]

This question is a little complicated, so I'll try to describe the
underlying issue in detail.

I'm using a Ruby script as a "glue" to link several engineering codes
together. To run each individual code, we utilize a production
submission system (call it 'PROD'). So I'm using Ruby to create input
files, submit the underlying engineering code run by invoking PROD with
the input file I've created. I then post-process the output of the
engineering code, and link it up to the next code by creating new input
files.

To invoke PROD, I'm using a system command of the type 'system( "PROD
options" )', where everything inside the single quotes is the command I
issue, and the options are PROD options.

This works pretty well until in one of the executions of an underlying
engineering code, the code prematurely terminates in the middle of a
run. If I take the identical input file and run it directly (using
*exactly* the same command as the system call above), it runs perfectly.

Are there some effects of "system" that I'm not aware of, being that I'm
a Nuby? One thought I had is that numerous system calls chew up memory
until I simply cannot run anything more.

Any speculations that anybody might have??

Respectfully, TPL

 

[Thomas Luedeke]

This question is a little complicated, so I'll try to describe the
underlying issue in detail.

I'm using a Ruby script as a "glue" to link several engineering codes
together. To run each individual code, we utilize a production
submission system (call it 'PROD'). So I'm using Ruby to create input
files, submit the underlying engineering code run by invoking PROD with
the input file I've created. I then post-process the output of the
engineering code, and link it up to the next code by creating new input
files.

To invoke PROD, I'm using a system command of the type 'system( "PROD
options" )', where everything inside the single quotes is the command I
issue, and the options are PROD options.

This works pretty well until in one of the executions of an underlying
engineering code, the code prematurely terminates in the middle of a
run. If I take the identical input file and run it directly (using
*exactly* the same command as the system call above), it runs perfectly.

Are there some effects of "system" that I'm not aware of, being that I'm
a Nuby? One thought I had is that numerous system calls chew up memory
until I simply cannot run anything more.

Any speculations that anybody might have??

Respectfully, TPL

Just as clarification, I'm not doing anything process-wise (nothing like
fork). I just make the system call, wait until it is done, move to the
area where the output files are, then start the linkage with the next
code.

 

[Thomas Luedeke]

Just as clarification, I'm not doing anything process-wise (nothing like
fork). I just make the system call, wait until it is done, move to the
area where the output files are, then start the linkage with the next
code.

Sorry, one last clarification. If I write a three line code running the
same input file, using the same system command, it runs to completion.
So something with regards to the lengthy script is interfering with the
process. Is this indicative of a memory issue?

 

[Dave Thomas]

Sorry, one last clarification. If I write a three line code running
the
same input file, using the same system command, it runs to
completion.
So something with regards to the lengthy script is interfering with
the
process. Is this indicative of a memory issue?
--

What's the termination status in $?. That may tell you why your
subprocess died.



Dave

 

[Thomas Luedeke]

What's the termination status in $?. That may tell you why your
subprocess died.



Dave

I'm pretty new at this - what is the command to do so?

 

[Robert Klemme]

I'm pretty new at this - what is the command to do so?

Place a "p $?" in the line after your system command.

On which platform and Ruby version are you? What shell are you using
when executing the command directly?

One effect of system you might not be aware of is that there will be a
shell invoked if you use a single string. I have no idea whether this
is related to your issue but it's certainly something to keep around in
the back of your mind.

Cheers

robert

 

[Dave Thomas]

I'm pretty new at this - what is the command to do so?

dave[ATCOCOA/Book 15:47:45] ri Process::Status
------------------------------------------------- Class: Process::Status
Process::Status encapsulates the information on the status of a
running or terminated system process. The built-in variable $? is
either nil or a Process::Status object.

fork { exit 99 } #=> 26557
Process.wait #=> 26557
$?.class #=> Process::Status
$?.to_i #=> 25344
$? >> 8 #=> 99
$?.stopped? #=> false
$?.exited? #=> true
$?.exitstatus #=> 99

Posix systems record information on processes using a 16-bit
integer. The lower bits record the process status (stopped,
exited, signaled) and the upper bits possibly contain additional
information (for example the program's return code in the case of
exited processes). Pre Ruby 1.8, these bits were exposed directly
to the Ruby program. Ruby now encapsulates these in a
Process::Status object. To maximize compatibility, however, these
objects retain a bit-oriented interface. In the descriptions that
follow, when we talk about the integer value of stat, we're
referring to this 16 bit value.


You can just use

p $?

to get information. If it was signaled (perhaps because a process
limit was exceeded) you can find the cause.

Dave

 

[Thomas Luedeke]

I'm pretty new at this - what is the command to do so?

dave[ATCOCOA/Book 15:47:45] ri Process::Status
------------------------------------------------- Class: Process::Status
Process::Status encapsulates the information on the status of a
running or terminated system process. The built-in variable $? is
either nil or a Process::Status object.

fork { exit 99 } #=> 26557
Process.wait #=> 26557
$?.class #=> Process::Status
$?.to_i #=> 25344
$? >> 8 #=> 99
$?.stopped? #=> false
$?.exited? #=> true
$?.exitstatus #=> 99

Posix systems record information on processes using a 16-bit
integer. The lower bits record the process status (stopped,
exited, signaled) and the upper bits possibly contain additional
information (for example the program's return code in the case of
exited processes). Pre Ruby 1.8, these bits were exposed directly
to the Ruby program. Ruby now encapsulates these in a
Process::Status object. To maximize compatibility, however, these
objects retain a bit-oriented interface. In the descriptions that
follow, when we talk about the integer value of stat, we're
referring to this 16 bit value.


You can just use

p $?

to get information. If it was signaled (perhaps because a process
limit was exceeded) you can find the cause.

Dave

Hmmm. This doesn't seem to mean much to me, but here's what it put out:

#<Process::Status: pid=1132,exited(1)>


Mean something to you? Sorry to be so dense, but I'm used to Korn shell
scripting, where things seem less separated from the processes.

 

[Thomas Luedeke]

I'm pretty new at this - what is the command to do so?

Place a "p $?" in the line after your system command.

On which platform and Ruby version are you? What shell are you using
when executing the command directly?

One effect of system you might not be aware of is that there will be a
shell invoked if you use a single string. I have no idea whether this
is related to your issue but it's certainly something to keep around in
the back of your mind.

Cheers

robert

I'm running on HP UX-11, with ruby-1.8.7-p22. The underlying UNIX shell
is Korn shell.

See my last message for the results of the p $?.

 

[Robert Klemme]

I'm running on HP UX-11, with ruby-1.8.7-p22. The underlying UNIX shell
is Korn shell.

Not Windows, that may make troubleshooting easier since on Windows
process handling is a bit different than on other systems.

See my last message for the results of the p $?.

There was at least an error because exit code != 0. The meaning of
exit codes is usually to be found in the documentation of the program.

Did you see any messages on the console?

If not and if you have permissions you could try to invoke the ruby
interpreter with "strace" (redirect stderr to a file) and maybe find
something near the end of the output of strace.

Kind regards

robert