• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Poll - Should FreeBSD support SHM like all other *nixes?

Should FreeBSD support the commonly-accepted SHM handling?

  • Yes! Fix that SHM thing so we are compatible with the rest of the world!

    Votes: 1 100.0%
  • No, let's be Posix religious! Let our users find out themselves why many apps show strange problems!

    Votes: 0 0.0%
  • No! Let's be even more deviant! Deactivate SHM by default!

    Votes: 0 0.0%

  • Total voters
    1

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#1
All relevant *xes like Linux, OpenBSD, Solaris etc handle SHM (shared memory) in a commonly accepted way.

Only FreeBSD devs stick religiously to a long-obsolete stupid Posix "standard" that no unixoid except FreeBSD still follows.

This has consequences:
To make Chromium work at all one is instructed to turn SHM off in its postinstall notes.
To make Gimp work without problems, one must turn off SHM.
To make KDE work without problems, one must turn off SHM.

And so on...
...causing useless waste of time and frustration to many, many users!

Who have to find out that they must manually edit /etc/sysctl.conf only to deactivate FreeBSD's broken SHM!
Just to make their programs work correctly.


So, please use your right to vote!
 

ShelLuser

Daemon

Thanks: 806
Messages: 2,012

#2
Uhm... I have FreeBSD 11.1 installed on my system and I run both KDE and Gimp without having turned off anything SHM-wise. At least not that I noticed. So I don't quite understand the issue here. "If it isn't broke...".

(edit)

Yups, think I found it (from GENERIC.11.1):

Code:
options         SYSVSHM                 # SYSV-style shared memory
options         SYSVMSG                 # SYSV-style message queues
options         SYSVSEM                 # SYSV-style semaphores
I now also question your comment regarding Solaris because that environment is also SYSV compliant, therefor I suspect it to use SHM as well. Took a brief look and found this:

On Oracle Solaris kernel parameter "max-shm-memory" is configured for the sizing of your shared Memory. This parameter will allow resizing of SGA. For example if this parameter is configured to 2GB than you cannot resize your memory_max_targetparameter exceeding this size. BY default 25% of memory will be allocated for Max Shared memory kernel parameter.
The kernel parameter "max-shm-memory" can be modified online using "prctl" utility, this feature is available from solaris-10 and later OS.
See this site. So quite frankly I don't think FreeBSD is as alone as you claim. But I definitely question the concerns you shared because I can't reproduce them.
 

Trihexagonal

Aspiring Daemon

Thanks: 312
Messages: 731

#3
Snurg, I can't comment on the rest of it, but I've never had the problem sited with graphics/gimp and it works flawlessly without me doing anything but build the port.

I can open and change img formats, use script-fu options, etc. and hardly a day goes by I don't use it. It's my default program to view images.
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#4
Please read the examples I listed. If that is not convincing enough, google "kern.ipc.shm_allow_removed=1" solution to see how many things break because of this problem. Use other keywords like solved, problem, issue in place of solution, too.
These are often hard-to-find issues, often regarding only things/features not everybody uses, making people think FreeBSD is bad, and go back to Linux...
 

Trihexagonal

Aspiring Daemon

Thanks: 312
Messages: 731

#5
I did, that's why I mentioned changing img formats:

This is keeping me from exporting images to JPG and PNG.
And script-fu:

Code:
(gimp:1140): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error
GIMP-Error: Plug-in crashed: "script-fu"
(/usr/local/libexec/gimp/2.2/plug-ins/script-fu)
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#7
tobik@
Meaning that FreeBSD does not have SHM at all...
Is it really a good idea to remove that thing every other *nix has, instead of fixing it?!?

Ah, this commit note explains it well, after 2nd reading...
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#8
But the problem is still that users have to add this in their sysctl.conf.
This should be the default in the kernel, and not implemented by a new sysctl.conf entry.

Then this would fix the issue without every user still having to disable it by hand.

Without fixing it in the kernel, many people who don't have manually changed their sysctl.conf will still stumble over issues it causes.
 

tobik@

Daemon
Developer

Thanks: 1,181
Messages: 1,771

#9
But the problem is still that users have to add this in their sysctl.conf.
This should be the default in the kernel, and not implemented by a new sysctl.conf entry.

Then this would fix the issue without every user still having to disable it by hand.

Without fixing it in the kernel, many people who don't have manually changed their sysctl.conf will still stumble over issues it causes.
I don't understand? The default in the kernel was changed already. That was the point of r289112. Since the default was changed you do not have to edit sysctl.conf at all.
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#10
I see in sys/kern/sysv_shm.c:
Code:
static int shm_allow_removed = 1;
Then the issue now is the, now misleading instruction in, say, chromium package notes which apparently still include the instruction to add that sysctl.conf variable.
These messages now all need to be removed...

Just now installed Chromium (from "latest" repo) to show:

Code:
# pkg install chromium
<snipped output until postinstall note>
For correct operation, shared memory support has to be enabled
in Chromium by performing the following command as root :

sysctl kern.ipc.shm_allow_removed=1

To preserve this setting across reboots, append the following
to /etc/sysctl.conf :

kern.ipc.shm_allow_removed=1
#
Do you think according notification of the maintainers via a PR is appropriate?

Then the KDE bug I mentioned is caused by another issue, as it apparently disappears when setting the environment variable QT_X11_NO_MITSHM=1...
 

Beastie

Daemon

Thanks: 418
Messages: 2,085

#11
In any case, GIMP has --no-shm. So, for that one at least, there's no need to change anything.
 

tobik@

Daemon
Developer

Thanks: 1,181
Messages: 1,771

#12
These messages now all need to be removed...
Sure they might need to be amended, but they can't be removed entirely since FreeBSD 10.3 and 10.4 are still supported and the default is different there.
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#13
In any case, GIMP has --no-shm. So, for that one at least, there's no need to change anything.
Not sure... if this option was added as a consequence of kern.ipc.shm_allow_removed defaulting to 0?
Couldn't the consequence be potential performance reduction?
 

Snurg

Aspiring Daemon

Thanks: 241
Messages: 691

#14
Sure they might need to be amended, but they can't be removed entirely since FreeBSD 10.3 and 10.4 are still supported and the default is different there.
Your knowledge is way better... do I understand you correctly that the default was changed from 11.0 on, so that the message could be changed that on versions prior to 11 sysctl.conf has to be modified?

Edit:
Gimp pkg postinstall note answers this:
Code:
gimp-app-2.8.22_1,1:
Always:
On FreeBSD 10.3 gimp can cause the following error.

(script-fu:3985): LibGimp-ERROR **: shmat() failed: Invalid argument
Could not attach to gimp shared memory segment

This can be fixed by setting kern.ipc.shm_allow_removed=1 in /etc/sysctl.conf.
FreeBSD 11.0-R and newer have this set by default.
OK, PR submitted to get the misleading Chromium postinstall note amended
 

achix

Well-Known Member

Thanks: 34
Messages: 270

#15
Been running postgersql with IPC SHM for ages, with no problems. Only slight tweaks very randomly and for truly exotic stuff (like pljava for instance). Postgresql recently moved to mmap tho.