Getting ENOPKG from a call to read( ) on OpenServer 5.0.7

[hay...@haydentech.com]

I have an obscure problem happening in our code. We have a product
that acts as a gateway between network clients and our command-line
application. This gateway is called from inetd, and serves to
multiplex data between the network client and our program. This
program compiles and runs on Linux, HP-UX, UnixWare, without issue.
99% of the time, it works fine on OpenServer too. One possibly very
important note: for the OpenServer binary, we compile on UnixWare using
the UDK and deploy with the BCM.

On a very small percentage of OpenServer machines (2 out of thousands)
on which this is deployed, the multiplexer does not work. An ENOPKG
error is returned from the call to read( ) the pty. The man page for
read(2) does not list ENOPKG as a possible error. The packages
installed on machines that work versus the machines that do not work
are identical.

The very little I was able to find online about the ENOPKG error did
not help at all. This link was the only similar problem I found, and
no solution was listed: http://aplawrence.com/Bofcusm/2342.html

What can cause read( ) to return ENOPKG?

Thanks,
Bill Hayden

[Bela Lubkin]

Bill Hayden wrote:

At a guess, for some reason the file descriptor is a STREAMS inode, and
the "tirdwr" module hasn't been pushed on the stream.

To reduce guessing, get `lsof` output for (1) your gateway program while
successfully connected, (2) your gateway program while it is having this
problem. To promote successful capture of #2, make a debug version of
your program that basically does:

/* error path */
if (errno_from_read == ENOPKG) {
char cmd[1000];
snprintf(cmd, sizeof(cmd), "(echo Trouble report for process %d on fd %d:; lsof -p%d) >> /tmp/problem_log", getpid(), problem_fd_number, getpid());
system(cmd);
}
/* not intended to be nice code */

Use it in-house if possible, else send to a customer site that's having
the problem. Collect the log, see if anything is apparent. If not,
post one process's worth of log + 1 process's worth of successful `lsof`
output, expose it to other eyes...

>Bela<