Thread: configure kernel for "IPC Namespace"

Does anyone know anything about the significance of the CONFIG_IPC_NS for using local sockets? It's a "when in doubt, say no" question (I said no) but I do have CONFIG_SYSVIPC set and CONFIG_SYSVIPC_SYSCTL, altho I don't think there's any option for the later in menuconfig et. al. I would have thought CONFIG_UNIX was all that's necessary for local sockets to work right.

I'm wondering because after thousands of successful connections, I'm having a wierd problem with accept():

Code:

struct sockaddr other;
socklen_t size;
int SD=accept(remote,&other,&size);

Causes accept to return errno 29 "Invalid argument" -- which I can't find any documentation about what this might mean, if it's anything different than errno 22: EINVAL.

However I did find this note on the web:
"This seems to be a recurring theme with redhat 7.x, there are numerous posts about this but as far we havent found a solution. Might i suggest a Kernel upgrade?"

I am running a newer kernel and have a hard time believing this is the problem as X, etc. use local sockets too. Even stranger is that in the current situation, this is what made the difference with accept:

Code:

struct sockaddr other, *ptr=&other;
socklen_t size;
int SD=accept(remote,ptr,&size);

I tried this numerous times both ways and don't understand why the 2nd version is "acceptable" whereas the first one (which is normative and always worked for me before) is not. Unfortunely, the connection returned then does not work properly...

Anyway, since the listening socket is PF_LOCAL, this "sockaddr" makes use of the "local namespace" which may or may not be "IPC Namespace".

I may try and recompile but I doubt this is the issue, somehow. Any thoughts or suggestions are, as usual, much appreciated.

Originally Posted by MK27

I may try and recompile but I doubt this is the issue, somehow. Any thoughts or suggestions are, as usual, much appreciated.

Suprise! It wasn't.

Once again, I got myself sorted out by RobSeace at "developerweb".

This was more of a gtk/multithreading problem.