> I suspect we already know the answer to this, but it's worth a small discussion.

> One of our developers spent a lot of time debugging an application whereby "socket(PF_UNIX, SOCK_DGRAM, 0)" was 
getting a "protocol not supported" error.

> The short story is that it turned out that he was doing a chroot() earlier in the code, and he had no reason to expect
 that would affect a later socket() call.

> In retrospect, it seems clear that chroot() makes it impossible for socket() to open /dev/socket/<pf> and therefore it
 gave the error it did.

> However, this behavior is sufficiently different from other POSIX platforms that it seems like, at a minimum, it would
 be nice to include in the documentation of chroot() that this is probably going to break other functions that may rely 
on the path layout, especially creating sockets.  And at a maximum, if there was some way around this, that would be 
great, but I can see that's not an easy problem to solve.

Working in a chroot is fun on QNX.  This isn't particular to socket().
pipe(), mqueue(), /proc (pidin, gdb, netstat) all have the same issue.
For socket() you can:
- run a stack under the chroot
    # io-pkt -p tcpip prefix=/chroot
    # ln -sP /chroot/dev/socket /dev/socket  <- if you want the same stack outside of the chroot
- have the app get a seed socket before the chroot() and call openfd() on it
  after the chroot().  The openfd will return a socket of the same
  domain, family, proto as the seed managed by the same stack.


I recently had to set up a chroot recently will all services present
but I had to invent some stuff that's not checked in yet.

-seanb