Help required: INTERRUPTED SYSTEM CALL

[Wendy Lim]

hi All
We have a custom built application which runs on
Digital Unix 4.0D. This application uses msgsnd and
msgrcv to process messages sent to/from a user defined
queue.

This application runs on at three different environments which are
identical in terms of the hard
disk space, memory etc. Only on the production environment does it
encounter the above error
after a specific event (the event is associated with day end processing
jobs on our system). The
" Interrupted system call error" causes the application
to exit. I put in debug statements and ran a test on the
production systems and found the following results:
1) The msgrcv() function returns -1
2) A perror() returns INTERRUPTED SYSTEM CALL
3) A call to msgctl()(this gives info on the message queue which is being
called) after the msgrcv() -1
return gives the following results:
msgctl.msg buffer = NULL
msgctl.msg buffer ltype = -7152
msgctl.msg last process send =0
msgctl.msg last process receive =0

I suspect the msgrcv function is returning -1 due to a
signal interrupt (errno=EINTR) but if my own process
is not sending a signal to the queue what is? I can
tell that my own process has not sent a signal from
the msgctl's last process send and last process
receive fields. Running the same application on my dev
environment and sending a deliberate error message
populates these two fields with the application pid.

How do i find out what an ltype of -7152 signifies.Our
ltypes are positive when we send to this queue.

Could it be a kernel setting? This is a strange error
as the same exe runs perfectly on all other
environments.

Thanks
Wendy Lim

[Serguei Patchkovskii]

Wendy Lim (wen...@pd.jaring.my) wrote:
: This application runs on at three different environments which are

: identical in terms of the hard
: disk space, memory etc. Only on the production environment does it
: encounter the above error
: after a specific event (the event is associated with day end processing
: jobs on our system). The
: " Interrupted system call error" causes the application
: to exit. I put in debug statements and ran a test on the
: production systems and found the following results:

Any correctly written program must be prepared to receive EINTR from msgrcv(),
as well as from most blocking system calls, and to deal with it (usually simply
by re-issuing msgrcv()). EINTR simply indicates that a non-ignored signal (see
"man 4 signal") arrived while msgrcv() was waiting for a message. This behavior
is clearly documented in the msgrcv manual page.

You can look up the rationaly for this behavior in any decent Unix programming
text.

/Serge.P

--
home page: http://www.cobalt.chem.ucalgary.ca/ps/