Summary: | dev-lang/php sandbox violation (because of net-snmp?) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | avenj, da5id2001, dan.dickey, defuebr, fhellmuth, gentoo-bugs, hwoarang, ikelos, it-knodel, Martin.vGagern, mgmadden, netmon, optiluca, pchrist, tampakrap, willard.dawson, zioalex |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 249496 | ||
Bug Blocks: | |||
Attachments: |
Build log
Build Log See Comment (--info & -pv) |
Description
Diego Elio Pettenò (RETIRED)
2010-06-19 20:53:10 UTC
Created attachment 235983 [details]
Build log
This is solved by running snmpcheck outside of sandbox. @netmon: you're the net-snmp maintainers, care to find an alternative? :) While bug 324777 and bug 324779 technically aren't duplicates, they show the same problem. A few posts on the forum claim that this somehow depends on snmpd running - http://forums.gentoo.org/viewtopic-t-832879.html Yes, post's about libsoup, but it's the same error. *** Bug 328053 has been marked as a duplicate of this bug. *** *** Bug 328459 has been marked as a duplicate of this bug. *** (In reply to comment #2) > This is solved by running snmpcheck outside of sandbox. Not for me it isn't. This was "fixed" in php5_2-sapi.eclass by adding an addpredict for the offending file. I can't say why this happens, but I've re-added the fix to the overlay ebuild (layman -a php, if you want to test) and will migrate it shortly, if there's no proper fix. (In reply to comment #7) > (In reply to comment #2) > > This is solved by running snmpcheck outside of sandbox. > > Not for me it isn't. > In the name of accuracy: Turns out, this was as I did not yet have my KDE environ configured on the system where I was running into this problem. With KDE up, I can actually run snmpcheck and then re-emerge php with no sandbox error. (In reply to comment #4) > A few posts on the forum claim that this somehow depends > on snmpd running - http://forums.gentoo.org/viewtopic-t-832879.html > Yes, post's about libsoup, but it's the same error. > I can confirm this bug on my system, Intel C2D running ~AMD64. I can post the build into and emerge --info if requested. I did try Willard's suggestion of running snmpcheck before, but the only thing that fixed was some broken Perl modules that I had to recompile. What I found to work, was copying the snmp.conf.example, to snmp.conf, and starting snmpd. Then sure enough, I restarted the emerge of PHP, and it finished without any Sandbox errors. I'm really not sure why it needs to run, but at least it fixed it for compile. And of course I stopped the service after I finished the emerge. *** Bug 329469 has been marked as a duplicate of this bug. *** Stupid question I'm sure, but has anyone tried merging w/ USE=-phar? Yep, stupid question. traced it down to snmp's add_mibdir, which is proving problematic to trace back to candidates in php... This is reproducible by just wiping the .index; it's a cache basically. The reason running snmp once fixes it is that it generates the cache on first read of the mibs dir... I must be special. I confirmed that snmpd wasn't running on my system -- "ps -ef | grep snmp". As per comment #10, I copied snmpd.conf.example to snmpd.conf. I then did /etc/init.d/snmpd start emerge php No joy. I stopped the snmpd service. As per a reply in the thread referenced in comment #4, I tried: emerge -C net-snmp && emerge libsoup && emerge net-snmp && emerge php Alas, still no joy. Going back to comment #10, I again tried: /etc/init.d/snmpd start emerge php Happy! Happy! Joy! Joy! I suggest that perhaps the default for phar support should be USE="-phar". I can't see that anyone who doesn't have snmpd running is going to want 'phar' support. When USE='phar' then there appears to be some additional configuration which needs to be checked. Point of reference: Needing to unmerge net-snmp and reemerging libsoup and then net-snmpd suggests to me that packages dependent on libsoup should be re-emerged after libsoup is updated. i.e. through library specific revdep-rebuild. I am not a dev and I am not programmer and I don't really know anything. Just thought I'd mention it. Currently, this is the completion message I get from libsoup: >>> Installing (1 of 1) net-libs/libsoup-2.30.2-r1 * Updating desktop mime database ... * Updating shared mime info database ... * No GNOME 2 GConf schemas found * Updating desktop mime database ... * Updating shared mime info database ... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. mabi: I wrote the original addpredict for that directory, way back in the sands of time with the first PHP5 on Gentoo. The problem isn't limited to PHP, but to ANY ebuild that runs a binary linked against some of net-snmp. This is due to the initialization handler for the net-snmp lib being sloppy. Use the addpredict for now, there's not really much other choice. Thanks for the analysis to ferring & robin. I've fixed the eblit and added a comment with a reference to this bug. If the error persists, please comment and/or reopen. Doesn't work for me, as the eblit fix is for src_install only, whereas I encounter the sandbox violation in src_compile already. The log from comment #1 looks pretty much like mine. It too reports sandbox violations after src_compile but before src_install. As a further indication, I get the sandbox error if I only execute "ebuild php-5.3.3.ebuild compile". Adn the environment doesn't mention the predict, as that eblit hasn't been sourced. Please someone REOPEN this report, I lack permission to do so. Created attachment 240675 [details]
Build Log
I too am still getting the same error message with 5.3.3. Attached is my build log. Also I am unable to reopen it.
Created attachment 240677 [details]
See Comment (--info & -pv)
Attached for reference if my --info, and emerge php -pv, to show use flags.
Crap, I didn't want to make a third comment, but I can't edit the others.. so... Starting /etc/init.d/snmpd does indeed let the compile finish correctly, again. (In reply to comment #20) > Crap, I didn't want to make a third comment, but I can't edit the others.. > so... Starting /etc/init.d/snmpd does indeed let the compile finish correctly, > again. > I noticed there are still problems with some systems regarding this,I personally have just emerged php-5.3.3 with this weeks updates and had no problems. Recently my x86_64 updated perl ,I ran perl-cleaner afterwards and it was responsible for updating some 64 files. If you have recently updated perl I would suggest that you do the same,if not already. Just in case this has some bearing on the problem,I do have the snmp.conf file in /etc ,so this may not be related, just a suggestion. Okay, now that's weird. The old addpredict was in src_install, so I figured adding it back in there would fix the problems. Have you guys synced recently and verified the addpredict is indeed in the src_install eblit? *** Bug 330555 has been marked as a duplicate of this bug. *** I --sync'd last night: -- Taranis php # cat php-5.3.3.ebuild | grep -c addpredict 0 -- So it doesn't look like it made it then... I also just resync'd, and it still shows 0. I hope I'm looking in the right place. However after this last sync, it compiles perfectly fine.... (In reply to comment #24) > So it doesn't look like it made it then... > I also just resync'd, and it still shows 0. I hope I'm looking in the right > place. > You are not :) The phase functions are located in individual files in files/eblits % grep -c addpredict files/eblits/src_install-1.eblit 1 Ah.. in that case, it is there now, which would explain why it worked when I tried to recompile. Sadly I can't go back in time to see if it was there for last night's sync... but I got a feeling I got it right before it was changed. hwoarang@Mystical ~/development/gentoo-cvs/gentoo-x86/dev-lang/php $ grep -c addpredict files/eblits/src_install-v1.eblit 1 Still php fails here with sandbox violations Synced 5' ago ps: Note the file is src_install-v1.eblit and not src_install-1.eblit (In reply to comment #22) > Have you guys synced recently and verified the addpredict is indeed in the > src_install eblit? Encountered error, synced, checked for CVS rev 1.6 of the eblit (1.5 added the supposed fix), ran "ebuild php-5.3.3.ebuild clean merge" again, encountered error again, ran "ebuild php-5.3.3.ebuild clean compile", still encountered error. So the problem surely is in compile now, no matter where it used to be in the past. Ok, I ran into this again tonight... this time I looked a bit more at the mibs/.index file. The main reason I did this, is when I tried to compile, and it filed, I noticed snmpd was already running. So, the mibs/.index file had a datestamp of Jul 30. When I stopped, started, and stopped snmpd, the datestamp changed to Aug 2nd. And at that point, php was able to compile perfectly fine. I'm not sure if this is noise, or helping, but I figured if it can help in the least, it's worth putting up :) 5.3.3-r1 compiled without me having to make any changes. This is a week after I had issues. Previously, it was compiled fine, then three days later it wouldn't. Anything change regarding this bug in r1? (In reply to comment #30) > 5.3.3-r1 compiled without me having to make any changes. This is a week after I > had issues. Previously, it was compiled fine, then three days later it > wouldn't. Anything change regarding this bug in r1? > Same story here with 5.3.3 building but 5.3.3-r1 not due to this recurring sandbox violation. I vote "most annoying bug" for the month. (In reply to comment #29) > Ok, I ran into this again tonight... this time I looked a bit more at the > mibs/.index file. The main reason I did this, is when I tried to compile, and > it filed, I noticed snmpd was already running. > So, the mibs/.index file had a datestamp of Jul 30. When I stopped, started, > and stopped snmpd, the datestamp changed to Aug 2nd. > And at that point, php was able to compile perfectly fine. > > I'm not sure if this is noise, or helping, but I figured if it can help in the > least, it's worth putting up :) > This sequence of starting and stopping snmpd did not work for me with dev-lang/php-5.3.3-r1. At this point, I cannot emerge this package. I've added the same addpredict we do for src_install to src_compile. The fix should be on the mirrors soon. Please resync and retry. Sorry for those cycles, this is a really ugly problem :/ I haven't touched the machine since the last recompile, and I was able to sync and compile without any issues. In the hopes of having fixed all issues, I'm closing this now. If the error creeps back up, please comment and/or reopen. |