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

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: [url]http://aplawrence.com/Bofcusm/2342.html[/url]

What can cause read( ) to return ENOPKG?

Thanks,
Bill Hayden

Bill Hayden wrote:
[color=blue]
> 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: [url]http://aplawrence.com/Bofcusm/2342.html[/url]
>
> What can cause read( ) to return ENOPKG?[/color]

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...
[color=blue]
>Bela<[/color]