I could finally capture the truss output.
The system() is failing at ioctl() with error EIO, and there is a SIGHUP due to
this.
[b]EIO = Some physical I/O error has occurred[/b]
Can anyone tell me why this error occurrs, and also all system calls fail
because of this error, till the process is
mspaper wrote:
> What can cause the child to receive SIGHUP? Once the
> system command fails due to this error, it cannot recover
> till the application is restarted
Depending on the shell (e.g. I only tried this with ksh93) you may try
to use...
-- snip --
trap '' SIGHUP
-- snip --
... to let the
mspaper writes:
> What can cause the child to receive SIGHUP?
A process normally receives SIGHUP when a "modem disconnect" is
detected on the controlling tty. See termio(7I).
It's possible for other processes to send SIGHUP using the kill(2)
system call. You can diagnose what's going on using t
Hi
What can cause the child to receive SIGHUP? Once the system command fails due
to this error, it cannot recover till the application is restarted
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolari
>If the return code is not -1 then the errno is not reliable.
>
>Look in /usr/include/sys/wait.h, specifically at the WEXITSTATUS() and
>friends macros. The return code is in the format of a stat returned from
> a call to wait functions.
>
>return value of 1, when put through the WEXITSTATUS ma
If the return code is not -1 then the errno is not reliable.
Look in /usr/include/sys/wait.h, specifically at the WEXITSTATUS() and
friends macros. The return code is in the format of a stat returned from
a call to wait functions.
return value of 1, when put through the WEXITSTATUS macro give
Thanks. I can try removing /dev/null and use truss. The manual copy of files
succeeds(the paths are logged by the application and the same paths are used to
do the manual copy).
This message posted from opensolaris.org
___
opensolaris-code mailing l
The other option is to remove the "2>/dev/null" from the commands below,
in which case there's a good chance you'll get an error message which
may explain the exit status.
As Dan says, truss can also help.
The obvious possibilities are either that one of the directories don't
exist or are unr
Please see my previous post, I have corrected a typo.
The return value is 1 (for rm and cp both)
For rm the errno = 0,
for cp the errno = 2
(I am not completely sure if this errno is associated with this system call as
there are some other system calls called prior to this. Unable to capture the
First, system returns either -1 for error, in which case, as is generally
true, you need to look at errno to find the reason for the failure;
otherwise it returns the exit code of the application.
Second, it's often useful to use truss to diagnose errors like this: Try
truss -t execve -a and
I am sorry, there is a typo, the return value is 1 in both the cases.
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
See man system.
"The invoker waits until the shell has completed, then
returns the exit status of the shell in the format specified
by waitpid(3C)"
The man page says rc == -1 is exec() or vfork() failed. Print the errno
to see why.
To get the real return code, after the call t
rm and cp return non zero values sometimes.
sprintf(tmp, "rm -rf %s/* 2>/dev/null\n", dest);
rc = system( tmp );
rc = 1
sprintf(tmp, "cp -r %s/* %s 2>/dev/null", source, dest);
rc = system( tmp );
rc = -1
The files exist and the paths are correct. I can do a manual copy but the
application fa
13 matches
Mail list logo
