posix shared memory shm_open problems.
Jim Schumacher
Greetings, Anyone here ever use POSIX shared memory on
Linux? I've been having problems with shm_open...
It's always returning -1 with errno set to "permission
denied" (EACCES). The same code is working on Solaris...
Here's what I'm trying to do:
{
int x;
errno = 0;
x = shm_open("/shmpath",O_RDWR|O_CREAT|O_EXCL,0666);
...
}
I've tried different path arguments. I've varied it with
"/tmp/shmpath" and with no leading slash "shmpath".
Always the same result. I've even tried duplicating the
shm path on the file system. That doesn't seem help.
Also I'm running this as a standard uid (not root).
System info
linux dist: redhat 7.2-1
kernel: 2.4.7
gcc version: 2.96
glibc version: 2.2.4-30
Regards,
- Jim Schumacher
mail == transeme at yahoo dot com
Michael Kerrisk
>Greetings, Anyone here ever use POSIX shared memory on
>Linux? I've been having problems with shm_open...
>It's always returning -1 with errno set to "permission
>denied" (EACCES). The same code is working on Solaris...
>
>Here's what I'm trying to do:
>
> {
> int x;
> errno = 0;
Why set errno before the call?
> x = shm_open("/shmpath",O_RDWR|O_CREAT|O_EXCL,0666);
> ...
> }
>
>I've tried different path arguments. I've varied it with
>"/tmp/shmpath" and with no leading slash "shmpath".
>Always the same result. I've even tried duplicating the
>shm path on the file system. That doesn't seem help.
>
>Also I'm running this as a standard uid (not root).
>
>System info
> linux dist: redhat 7.2-1
> kernel: 2.4.7
> gcc version: 2.96
> glibc version: 2.2.4-30
I haven't tried it with this particular kernel, but shm_open() does work for me,
and it's not clear why it doesn't for you in this example. (In general you need
kernel 2.4.x, and glibc 2.2 (or later).)
When you run mount(8), do you see a shared memory file system mounted on
/dev/shm?
Cheers
Michael
Jim Schumacher
creates an entry in /dev/shm that corresponds to the
shm_open pathname. The permissions on this directory
was...
% ls -ld /dev/shm
drwxr-xr-t 2 root root 0 Oct 24 15:00 /dev/shm
So I had no write permission. Hence the "permission denied"
errors.
Other shm observations on Linux:
The leading slash on the filename is not needed:
shm_open("/foo",...) and shm_open("foo",...) will
correspond to the same shared memory block.
This is unlike Solaris - the Solaris shm_open requires
that leading slash.
Like Solaris there can be no subsequent slash after the
leading one.
- Jim Schumacher
mail transeme at yahoo dot com
p.s Michael: I don't make a habit of setting errno. It's just when I
was hunting for this bug I wanted to be absolutely sure that
shm_open was setting the errno and it wasn't some left over
value...
Kasper Dupont
>
> I discovered the problem. For posix shared mem. Linux
> creates an entry in /dev/shm that corresponds to the
> shm_open pathname. The permissions on this directory
> was...
> % ls -ld /dev/shm
> drwxr-xr-t 2 root root 0 Oct 24 15:00 /dev/shm
>
> So I had no write permission. Hence the "permission denied"
> errors.
How did you get those permissions on /dev/shm? I have this:
[kasperd@horse08:pts/9:kasperd] ls -ld /dev/shm
drwxrwxrwt 2 root root 0 Oct 22 18:03 /dev/shm
[kasperd@horse08:pts/9:kasperd]
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
Don't do this at home kids: touch -- -rf
Michael Kerrisk
>I discovered the problem. For posix shared mem. Linux
>creates an entry in /dev/shm that corresponds to the
>shm_open pathname. The permissions on this directory
>was...
>% ls -ld /dev/shm
>drwxr-xr-t 2 root root 0 Oct 24 15:00 /dev/shm
>
>So I had no write permission. Hence the "permission denied"
>errors.
>
>Other shm observations on Linux:
> The leading slash on the filename is not needed:
> shm_open("/foo",...) and shm_open("foo",...) will
> correspond to the same shared memory block.
> This is unlike Solaris - the Solaris shm_open requires
> that leading slash.
Yes, but be aware that SUSv3 says the following:
<<
The name argument conforms to the construction rules for a pathname. If name
begins with the slash character, then processes calling shm_open() with the same
value of name refer to the same shared memory object, as long as that name has
not been removed. If name does not begin with the slash character, the effect
is implementation-defined. The interpretation of slash characters other than
the leading slash character in name is implementation-defined.
>>
So, thought you do not happen to need that leading slash in Unix, for
portability, you should include it.
>p.s Michael: I don't make a habit of setting errno. It's just when I
>was hunting for this bug I wanted to be absolutely sure that
>shm_open was setting the errno and it wasn't some left over
>value...
Yep - know the syndrome ;-)...
Cheers
Michael