| View previous topic :: View next topic |
| Author |
Message |
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
 Posted: Tue Nov 19, 2013 1:14 am Post subject: sem_open implementation on chromium install |
 |
|
hi, I'm trying to emerge chromium 32.0.1700.14 but am stuck at this:
| Code: | | ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. |
since the line before I see: File "/usr/lib64/python2.7/multiprocessing/synchronize.py", line 59
I'm guessing it has something to do with python!? although google lead me to set my /dev/shm in fstab - that didn't work for me (perhaps I did it wrong) 
I use gnome 3.8 with systemd if it helps.
thanks for helping in advance |
|
| Back to top |
|
 |
eyoung100
Veteran
Joined: 23 Jan 2004
Posts: 1428
|
|
| Back to top |
|
|
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
| Posted: Tue Nov 19, 2013 5:54 pm Post subject: |
|
|
| eyoung100 wrote: | | Code: | | eselect python list |
|
| Code: | eselect python list
Available Python interpreters:
[1] python2.7
[2] python3.2 *
[3] python3.3 |
make.conf:
| Code: | PYTHON_TARGETS="python2_7 python3_2 python3_3"
PYTHON_SINGLE_TARGET="python2_7"
USE_PYTHON='2.7 3.2 3.3' |
any idea? |
|
| Back to top |
|
|
eyoung100
Veteran
Joined: 23 Jan 2004
Posts: 1428
|
|
| Back to top |
|
|
jhon987
Guru
Joined: 18 Nov 2013
Posts: 302
|
| Posted: Tue Nov 19, 2013 6:09 pm Post subject: |
|
|
| eyoung100 wrote: | | Code: | emerge -av chromium
Answer N |
|
| Code: | from .queues import SimpleQueue
File "/usr/lib64/python2.7/multiprocessing/queues.py", line 48, in <module>
from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition
File "/usr/lib64/python2.7/multiprocessing/synchronize.py", line 59, in <module>
" function, see issue 3770.")
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
* ERROR: www-client/chromium-32.0.1700.14::gentoo failed (configure phase):
* (no error message) |
perhaps this might shed more light on the matter? |
|
| Back to top |
|
|
snkmoorthy
Guru
Joined: 19 Nov 2002
Posts: 376
|
| Posted: Thu Dec 05, 2013 1:35 am Post subject: |
|
|
| I downgraded to 2.7.5-r3 till a fix is found. |
|
| Back to top |
|
|
elmicz1
n00b
Joined: 15 Mar 2013
Posts: 5
|
| Posted: Sat Dec 14, 2013 7:43 am Post subject: |
|
|
I was stuck with the same error but here is what did the trick for me:
Following this post http://stackoverflow.com/questions/9015010/python-sem-open-error it seems that during the upgrade to Gnome3.8 and Systemd /dev/shm was not mounted. (I did a full rebuild of @world since I wasn't able to get systemd started first).
| Quote: |
1. Add this line to /etc/fstab EDITED: When using OpenRC, otherwise comment it out
| Code: | | tmpfs /dev/shm tmpfs defaults 0 0 |
2. Mount /dev/shm EDITED: When running OpenRC
3. Rebuild Python
| Code: | | emerge -qa python:2.7 python |
4. Rebulid all Python stuff
5. (optional)
| Code: | | emerge @preserved-rebuild && revdep-rebuild -q |
6. Install chromium/update world
| Code: | | emerge -DuNq @world |
|
I hope this works for others as well.
Last edited by elmicz1 on Thu Dec 19, 2013 8:43 pm; edited 1 time in total |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 16, 2013 5:27 am Post subject: |
|
|
Interesting, elmicz1. I've had this in /etc/fstab for ages:
| Code: | # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
|
ISTR some daemon mounts things early nowadays, but I've always kept that line in fstab, and never had the /dev one (which is handled by CONFIG_DEVTMPFS_MOUNT, and checked by some script.) Sorry for vague, bit tired. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Mon Dec 16, 2013 6:29 am Post subject: |
|
|
The /dev/shm /etc/fstab redundancy was discussed back in this thread due to udev/devtmpfs. However far back the glibc-2.2 shared memory requirement started. My install here only dates back to 2008. The comment line telling the user to do this in /etc/fstab stuck in however many released stage 3s for a time (prior to May 2013 udev changes). My amd64 system installed in Nov 2012 still had the reference.
See also.
Elmicz1, you shouldn't need the tmpfs /dev/shm line in your /etc/fstab since udev embedded into the systemd is supposed to handle it for you.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 16, 2013 7:30 pm Post subject: |
|
|
Yes I read that a while ago, but to me it's similar to CONFIG_DEVTMPFS_MOUNT, which is technically redundant in the same manner.
However it does not hurt, and means that things are working should a userland-component fail. After all, there is no situation where I do not want shared-memory working, so I'd rather get it out of the way and done, robustly. Though I guess I need a relatime option in fstab.
Personally I prefer to think of udev as being redundant in this situation, since it's unnecessary, but I'm all for the initscript ensuring the mount has happened. Nor is there anything wrong with ideas being prototyped in userland, and then moved back into the kernel, of which devtmpfs is an example. I just wish it were acknowledged that that is what is happening. Of course no-one would develop software like that if they had any sense: they'd prototype and then feed it back in based on testing, before pushing it to end-users for acceptance testing.
Oh and that they'd swallow their pride and admit they messed up network naming big time, and move that into the kernel for admins who actually need it, and forget about trying to do that on a desktop or laptop, or smaller, where it simply is a waste of time. Just the latter will do, since they're unlikely ever to admit a mistake (just draw attention to it 4 years later, as justification for the next dumbass idea.) |
|
| Back to top |
|
|
elmicz1
n00b
Joined: 15 Mar 2013
Posts: 5
|
| Posted: Thu Dec 19, 2013 8:42 pm Post subject: |
|
|
| Navar wrote: | | Elmicz1, you shouldn't need the tmpfs /dev/shm line in your /etc/fstab since udev embedded into the systemd is supposed to handle it for you. |
Thanks for pointing that out, Navar. I removed that line from /etc/fstab, rebooted, rebuild python and then build chromium. I guess the problem was that the line was missing when I rebuild python on openrc while trying to install systemd. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Dec 20, 2013 12:35 am Post subject: |
|
|
My bad, udev is not redundant when it's starting in initramfs, and there's no /etc/fstab.
For those of us running without an initramfs, the line is still useful. There's an argument for having it as a kernel-option, same as devtmpfs mount, but I guess even an embedded system has initscripts. |
|
| Back to top |
|
|
lost-distance
n00b
Joined: 10 Apr 2003
Posts: 73
|
| Posted: Mon Dec 23, 2013 4:40 pm Post subject: |
|
|
I encountered the same sem_open failure when trying to build www-client/chromium-32.0.1700.68.
My solution was to re-emerge dev-lang/python-2.7.5-r3. |
|
| Back to top |
|
|
Angrychile
Apprentice
Joined: 27 Oct 2009
Posts: 235
|
| Posted: Fri Jan 10, 2014 3:15 am Post subject: |
|
|
Not to cause some forum necromancy, but I have a theory. This error showed up for both python2.7 and 3.3 on my machine--to trigger, I did something like | Code: | | python2 -c 'import multiprocessing.synchronize' |
. I made no changes to fstab (I'm using openrc), but simply re-emerging both fixed this.
Not sure, but I believe this is the first time I emerged either python since I installed a month ago, ie., it may be the pythons I had before the re-emerge installed were from the stage3 tarball I used to install. Could that have anything to do with this?
_________________
hola |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Thu Feb 06, 2014 1:49 am Post subject: |
|
|
| steveL wrote: | My bad, udev is not redundant when it's starting in initramfs, and there's no /etc/fstab.
For those of us running without an initramfs, the line is still useful. There's an argument for having it as a kernel-option, same as devtmpfs mount, but I guess even an embedded system has initscripts. |
Sorry, I don't follow. Would you care to elaborate further? Was there something Ssuominen wasn't saying or some other situation I'm missing? I am on OpenRC, no initramfs for 5+ years and the old shm /dev/shm tmpfs etc. line is removed/commented out per the past threads mentioned. My limited understanding was either the kernel (configured with support) already provided the respective dev node for same and/or udev functionality, via leveraged kernel support, provided sometime after version ~170ish. Mount showed respective (dev)tmpfs still being mounted since. So I didn't spend further time investigating the details and went about my merry way. If I switch to eudev or some such am I going to need such setups back in fstab given a kernel >3.4?
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Thu Feb 06, 2014 1:52 am Post subject: |
|
|
@Angrychile, no idea. Maybe an issue of not running python-updater. I did not run into these issues with my build (amd64) of chromium-32.0.1700.102, but maybe I will during today's update.  Python-2.7.5-r3 is what is installed. I think the same is true for my x86 setups but I haven't checked.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Feb 07, 2014 7:55 am Post subject: |
|
|
| Navar wrote: | | Sorry, I don't follow. Would you care to elaborate further? |
Firstly, don't worry about your system: it's mounted automatically.
The point I was making was only that it's redundant in the same way as CONFIG_DEVTMPFS_MOUNT is, in that both are handled by a service during startup, so there's no need for the alternative. However, if your services aren't starting for some reason, you still want libc operational. Not that things would fall over that badly, but I don't know the ins and outs, and I'd rather just mount it from fstab and let the service say it's already mounted. The latter doesn't bother me any, in fact it reassures me.
Assuming that isn't all outdated and it's now done differently to how I remember. In any event, if it's that important I don't think it should be down to initscripts to sort out. Either that, or we stop pretending anything implemented in shell must be the devil's work ;)
I don't like the idea of a system that won't operate without udev either, if I'm honest, let alone dbus. The whole thing just feels icky. |
|
| Back to top |
|
|
diablo465
Apprentice
Joined: 10 Sep 2013
Posts: 194
|
| Posted: Fri Feb 21, 2014 1:27 pm Post subject: |
|
|
| same problem here, no solution so far. |
|
| Back to top |
|
|
AgBr
Apprentice
Joined: 06 Nov 2010
Posts: 195
|
| Posted: Sat Feb 22, 2014 11:48 am Post subject: |
|
|
| lost-distance wrote: | I encountered the same sem_open failure when trying to build www-client/chromium-32.0.1700.68.
My solution was to re-emerge dev-lang/python-2.7.5-r3. |
Excuse my ignorance. But how can I reemerge a certain version of a package? I have 2.7 and 3.3 installed while having 2.7 active. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Feb 22, 2014 12:06 pm Post subject: |
|
|
| AgBr wrote: | | Excuse my ignorance. But how can I reemerge a certain version of a package? I have 2.7 and 3.3 installed while having 2.7 active. |
AgBr ... you can use the slot designation like so:
| Code: | | # emerge --oneshot python:2.7 |
... similarly for python:3.3
You might also explicitly stipulate the package version required ...
| Code: | | # emerge --oneshot =dev-lang/python-2.7.5-r3 |
HTH & best ... khay |
|
| Back to top |
|
|
AgBr
Apprentice
Joined: 06 Nov 2010
Posts: 195
|
| Posted: Sat Feb 22, 2014 1:43 pm Post subject: |
|
|
| khayyam wrote: | | AgBr wrote: | | Excuse my ignorance. But how can I reemerge a certain version of a package? I have 2.7 and 3.3 installed while having 2.7 active. |
AgBr ... you can use the slot designation like so:
| Code: | | # emerge --oneshot python:2.7 |
... similarly for python:3.3
You might also explicitly stipulate the package version required ...
| Code: | | # emerge --oneshot =dev-lang/python-2.7.5-r3 |
HTH & best ... khay |
Thank you. It's running right now. I hope this will help to solve the problem with chromium. |
|
| Back to top |
|
|
marciocarmona
n00b
Joined: 08 Mar 2014
Posts: 1
|
| Posted: Sat Mar 08, 2014 10:18 pm Post subject: |
|
|
| lost-distance wrote: | I encountered the same sem_open failure when trying to build www-client/chromium-32.0.1700.68.
My solution was to re-emerge dev-lang/python-2.7.5-r3. |
Worked like a charm! Thx dude!  |
|
| Back to top |
|
|
burzmali
Apprentice
Joined: 18 Apr 2002
Posts: 238
Location: ca
|
| Posted: Thu Jul 03, 2014 9:15 pm Post subject: |
|
|
I ran into this issue with a new install running meld and rebuilding python fixed it for me.
Probably we should file a bug...
_________________
burzmali
www.burzmali.net |
|
| Back to top |
|
|
|
Portage & Programming
