I have been using Google Chrome on my Slackware unix box for about 6 months now. So I know the program does work on Slackware. But -- I recently had to recompile and upgrade my linux kernel from 3.17.8 to 3.18.9 in order to upgrade the system's ATI R9 290 graphics card behavior for games, and I also did it in hopes of eliminating a google-chrome ERROR start up message which says "ERROR:sandbox_linux.cc(325)] InitializeSandbox() called with multiple threads in process gpu-process" , BUT shortly afterward I started getting the Aw, Snap! blue screen of death and can no longer web browse.
I tried all the obvious repair tricks, deleting the google ~/.cache/... and ~/.config/..., reinstalling chrome (and got & compiled the latest releases google-chrome-41.0.2272.101-x86_64-1, chromium-41.0.2272.101-x86_64-1alien, ), to the extreme attempt in desperation of completely re-installing Slackware linux from scratch on a new hard drive assuming I must have damaged a library or something somewhere and even recompiling the kernel both with and without seccomp trusted byte code, and switching back and forth between mozilla-nss-3.15.2-x86_64-2, and seamonkey-solibs-2.21-x86_64-1 to see if either library set caused a problem...
And just to be safe, I installed all the 32 bit multilib compatability libraries for every 64 bit package I installed, and added the following non-standard libraries to the system which some websites suggested might have been needed in the past for Chrome, even if they aren't anymore...
ORBit2-2.14.19-x86_64-1_SBo
GConf-3.2.6-x86_64-1
pciutils-3.2.0-x86_64-2 # To fix slackware libpci.a not being a dynamic lib.
libgnome-keyring-3.8.0-x86_64-1
gnome-keyring-3.8.2-x86_64-1
freealut-1.1.0-x86_64-1ponce
freeglut-2.8.0-x86_64-1
OpenAL-1.16.0-x86_64-1_SBo
And for fonts, I have true microsoft windows Times, and Arial, and also dejavu-fonts-ttf-2.34-noarch-1, and fslsfonts-1.0.4-x86_64-1, which have always been sufficient in the past, but to be safe I added liberation-fonts-ttf-1.07.2-noarch-1 recently; but it didn't help.
The present ldd of chromium shows the following libraries, all of them being stock for slackware64 14.1 except the ones listed above; As you can see, there are NO missing libraries.
linux-vdso.so.1 (0x00007fff60fda000)
librt.so.1 => /lib64/librt.so.1 (0x00007f8a60296000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8a60091000)
libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0(0x00007f8a5fe42000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f8a5fb18000)
libnss3.so => /usr/lib64/libnss3.so (0x00007f8a5f7db000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00007f8a5f5ae000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f8a5f383000)
libplc4.so => /usr/lib64/libplc4.so (0x00007f8a5f17e000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00007f8a5ef41000)
libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f8a5ebe8000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f8a5e9ad000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f8a5e71c000)
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f8a5e510000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f8a5e21b000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f8a5dfd1000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f8a5dc97000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f8a5da87000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f8a5d87d000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f8a5d66c000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f8a5d466000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f8a5d25d000)
libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f8a5d05b000)
libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007f8a5cd65000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f8a5cb63000)
libXtst.so.6 => /usr/lib64/libXtst.so.6 (0x00007f8a5c95e000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f8a5c754000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f8a5c52b000)
libcups.so.2 => /usr/lib64/libcups.so.2 (0x00007f8a5c2e0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a5c0c2000)
libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f8a5be7c000)
libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f8a5b848000)
libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f8a5b595000)
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f8a5b375000)
libXss.so.1 => /usr/lib64/libXss.so.1 (0x00007f8a5b172000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8a5ae6f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8a5ab6d000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f8a5a957000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8a5a58d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8a679db000)
libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f8a5a385000)
libplds4.so => /usr/lib64/libplds4.so (0x00007f8a5a182000)
libz.so.1 => /lib64/libz.so.1 (0x00007f8a59f6c000)
libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f8a59d69000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8a59b4e000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f8a5993e000)
libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f8a59719000)
libpixman-1.so.0 => /usr/lib64/../lib64/libpixman-1.so.0 (0x00007f8a59470000)
libxcb-shm.so.0 => /usr/lib64/../lib64/libxcb-shm.so.0 (0x00007f8a5926e000)
libX11-xcb.so.1 => /usr/lib64/../lib64/libX11-xcb.so.1 (0x00007f8a5906d000)
libxcb-render.so.0 => /usr/lib64/../lib64/libxcb-render.so.0 (0x00007f8a58e63000)
libxcb.so.1 => /usr/lib64/../lib64/libxcb.so.1 (0x00007f8a58c46000)
libXau.so.6 => /usr/lib64/../lib64/libXau.so.6 (0x00007f8a58a43000)
libXdmcp.so.6 => /usr/lib64/../lib64/libXdmcp.so.6 (0x00007f8a5883d000)
libpangoft2-1.0.so.0 => /usr/lib64/../lib64/libpangoft2-1.0.so.0 (0x00007f8a58629000)
libgthread-2.0.so.0 => /usr/lib64/../lib64/libgthread-2.0.so.0 (0x00007f8a58428000)
libharfbuzz.so.0 => /usr/lib64/../lib64/libharfbuzz.so.0 (0x00007f8a58196000)
libicule.so.51 => /usr/lib64/../lib64/libicule.so.51 (0x00007f8a57f40000)
libicuuc.so.51 => /usr/lib64/../lib64/libicuuc.so.51 (0x00007f8a57bd6000)
libicudata.so.51 => /usr/lib64/../lib64/libicudata.so.51 (0x00007f8a5648b000)
libssl.so.1 => /lib64/libssl.so.1 (0x00007f8a56220000)
libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007f8a55e47000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8a55c0e000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f8a55a0b000)
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f8a557e8000)
But -- it's all no good. Both chrome and chromium (which I can successfully compile from scratch without any problems), give the same blue screen of death with "Aw, Snap!" at start-up, and neither will even allow the display of the "about chrome page" or anything else. It's is 100% unable to display anything except popup dialogs. Please note: Firefox, several OpenGL games, and even GPU accerated ones like Trine, and all other normal slackware X11 applications work perfectly. There is no firewall, or ad-blocking, or anything installed on this system at the moment. Yet -- the problem persists.
I decided to enable the error reporting feature of chrome to let them know but that merely caused a list of error messages to scroll by in the terminal saying that the certificate of authority of google could not be verified locally... Which made me laugh, and decide to post here -- for Google probably believes there is nothing wrong with their browser under linux -- because they aren't receiveing any error messages... and never will...
So, how can I isolate what is causing the problem? (Or at very least get bug reporting working?!) I'm willing to try on chrome or chromium .
For my last attempt before giving up, on chromium, I tried assuming it was a gpu-related problem, and perhaps a kernel setting messed it up -- so I looked for clues on how to turn off the gpu completely.
I can not tell if these flags are specific to chrome, or if they will work with chrome and chromium both, but here's what I did from the command line:
chromium --disable-accelerated-composting --disable-accelerated-layers --disable-accelerated-2d-canvas --blacklist-webgl --blacklist-accelerated-composting --enable-logging=stderr --v=1 www.yahoo.com 2> ~/chrome_err.log
However, that didn't even get rid of the original error message that made me want to upgrade in the first place, for it still reports ERROR: multiple threads for gpu.
chrome_err.log:
[1725:1725:0324/120300:VERBOSE1:breakpad_linux.cc(1659)] Breakpad disabled
[1:1:0324/120300:VERBOSE1:zygote_main_linux.cc(600)] ZygoteMain: initializing 2 fork delegates
[1:1:0324/120300:VERBOSE1:nacl_fork_delegate_linux.cc(142)] NaClForkDelegate::Init()
[1:1:0324/120300:VERBOSE1:nacl_fork_delegate_linux.cc(142)] NaClForkDelegate::Init()
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "726124521725-usiuc172onlf7t4ind7sf2detm950t7n.apps.googleusercontent.com" for API key GOOGLE_CLIENT_ID_MAIN
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "ll1NK5GBOrAUb6zSbcgAX1Q7" for API key GOOGLE_CLIENT_SECRET_MAIN
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "726124521725-usiuc172onlf7t4ind7sf2detm950t7n.apps.googleusercontent.com" for API key GOOGLE_CLIENT_ID_CLOUD_PRINT
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "ll1NK5GBOrAUb6zSbcgAX1Q7" for API key GOOGLE_CLIENT_SECRET_CLOUD_PRINT
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "726124521725-usiuc172onlf7t4ind7sf2detm950t7n.apps.googleusercontent.com" for API key GOOGLE_CLIENT_ID_REMOTING
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "ll1NK5GBOrAUb6zSbcgAX1Q7" for API key GOOGLE_CLIENT_SECRET_REMOTING
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "726124521725-usiuc172onlf7t4ind7sf2detm950t7n.apps.googleusercontent.com" for API key GOOGLE_CLIENT_ID_REMOTING_HOST
[1725:1748:0324/120300:VERBOSE1:google_api_keys.cc(237)] Using default value "ll1NK5GBOrAUb6zSbcgAX1Q7" for API key GOOGLE_CLIENT_SECRET_REMOTING_HOST
[1725:1725:0324/120300:VERBOSE1:pref_proxy_config_tracker_impl.cc(148)] 0x7fef8a158280: set chrome proxy config service to 0x7fef8a1899f0
[1725:1725:0324/120300:VERBOSE1:pref_proxy_config_tracker_impl.cc(277)] 0x7fef8a158280: Done pushing proxy to UpdateProxyConfig
[1725:1725:0324/120300:VERBOSE1:app_list_syncable_service_factory.cc(55)] AppListSyncableServiceFactory()
[1725:1748:0324/120300:VERBOSE1:multi_log_ct_verifier.cc(76)] Adding CT log: Google 'Pilot' log
[1725:1748:0324/120300:VERBOSE1:multi_log_ct_verifier.cc(76)] Adding CT log: Google 'Aviator' log
[1725:1748:0324/120300:VERBOSE1:multi_log_ct_verifier.cc(76)] Adding CT log: DigiCert Log Server
[1725:1725:0324/120300:VERBOSE1:bluetooth_low_energy_event_router.cc(192)] Initializing BluetoothLowEnergyEventRouter.
[1725:1725:0324/120300:VERBOSE1:bluetooth_low_energy_event_router.cc(195)] Bluetooth not supported on the current platform.
[1725:1725:0324/120300:VERBOSE1:app_list_syncable_service_factory.cc(45)] BuildInstanceFor: Default (0x7fef8a19bde0)
[1725:1725:0324/120300:VERBOSE1:pref_proxy_config_tracker_impl.cc(148)] 0x7fef8a287cb0: set chrome proxy config service to 0x7fef8a288370
[1725:1725:0324/120300:VERBOSE1:pref_proxy_config_tracker_impl.cc(277)] 0x7fef8a287cb0: Done pushing proxy to UpdateProxyConfig
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Bookmark Manager
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Cloud Print
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Web Store
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Chromium
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Settings
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension Google Now
[1725:1725:0324/120300:VERBOSE1:extension_service.cc(1533)] AddComponentExtension CryptoTokenExtension
[1725:1725:0324/120300:VERBOSE1:app_list_syncable_service.cc(284)] 0x7fef8a26c8c0: AppListSyncableService: InitializeWithService.
[1725:1725:0324/120300:VERBOSE1:app_list_syncable_service.cc(837)] 0x7fef8a26c8c0: SyncStarted: Flare.
[1725:1725:0324/120300:WARNING:data_reduction_proxy_settings.cc(365)] SPDY proxy OFF at startup
[1725:1725:0324/120300:VERBOSE1:account_reconcilor.cc(70)] AccountReconcilor::AccountReconcilor
[1725:1725:0324/120300:VERBOSE1:account_reconcilor.cc(80)] AccountReconcilor::Initialize
[1725:1725:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(182)] Registering EV whitelist component.
[1725:1725:0324/120300:VERBOSE1:component_updater_service.cc(267)] CrxUpdateService starting up
[1725:1764:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(68)] Initial load: reading EV whitelist from file: /home/andrew3/.config/chromium/ev_hashes_whitelist.bin
[1725:1725:0324/120300:VERBOSE1:startup_browser_creator_impl.cc(587)] StartupBrowserCreatorImpl::ProcessStartupURLs
[1725:1751:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(147)] Verifying install: /home/andrew3/.config/chromium/EVWhitelist/6/_platform_specific/all/ev_hashes_whitelist.bin
[1725:1725:0324/120300:VERBOSE1:startup_browser_creator_impl.cc(595)] Pref: default
[1725:1764:0324/120300:VERBOSE1:packed_ct_ev_whitelist.cc(62)] Uncompressing EV whitelist of size 1113849
[1725:1751:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(159)] Whitelist size: 1113849
[1725:1744:0324/120300:VERBOSE1:crl_set_fetcher.cc(103)] Loaded 201209 bytes of CRL set from disk
[1725:1748:0324/120300:VERBOSE1:crl_set_fetcher.cc(125)] Installed CRL set #2146
[1725:1725:0324/120300:VERBOSE1:password_store_factory.cc(207)] Password storage detected desktop environment: (unknown)
[1725:1725:0324/120300:WARNING:password_store_factory.cc(237)] Using basic (unencrypted) store for password storage. See http://code.google.com/p/chromium/wiki/LinuxPasswordStorage for more information about password storage options.
[7:7:0324/120300:VERBOSE1:sandbox_linux.cc(64)] Activated seccomp-bpf sandbox for process type: renderer.
[7:7:0324/120300:VERBOSE1:child_thread.cc(245)] Mojo is disabled on child
[1725:1725:0324/120300:VERBOSE1:component_updater_service.cc(267)] CrxUpdateService starting up
[1725:1725:0324/120300:VERBOSE1:component_updater_service.cc(274)] First update attempt will take place in 360 seconds
[1725:1725:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(134)] Component ready, version 6 in /home/andrew3/.config/chromium/EVWhitelist/6
[1725:1742:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(36)] Reading new EV whitelist from file: /home/andrew3/.config/chromium/EVWhitelist/6/_platform_specific/all/ev_hashes_whitelist.bin
[1725:1764:0324/120300:VERBOSE1:ev_whitelist_component_installer.cc(88)] EV whitelist: Sucessfully loaded initial data.
[1725:1748:0324/120300:VERBOSE1:packed_ct_ev_whitelist.cc(26)] Setting new EV Certs whitelist.
[1725:1742:0324/120300:VERBOSE1:packed_ct_ev_whitelist.cc(62)] Uncompressing EV whitelist of size 1113849
[1725:1748:0324/120300:VERBOSE1:packed_ct_ev_whitelist.cc(26)] Setting new EV Certs whitelist.
[1754:1754:0324/120300:ERROR:sandbox_linux.cc(325)] InitializeSandbox() called with multiple threads in process gpu-process
[1754:1754:0324/120300:VERBOSE1:child_thread.cc(245)] Mojo is disabled on child
[12:12:0324/120300:VERBOSE1:sandbox_linux.cc(64)] Activated seccomp-bpf sandbox for process type: utility.
[12:12:0324/120300:VERBOSE1:child_thread.cc(245)] Mojo is disabled on child
[1725:1725:0324/120302:VERBOSE1:account_reconcilor.cc(98)] AccountReconcilor::Shutdown
[1725:1725:0324/120302:VERBOSE1:merge_session_helper.cc(212)] MergeSessionHelper::CancelAll
[1725:1725:0324/120302:VERBOSE1:account_reconcilor.cc(74)] AccountReconcilor::~AccountReconcilor
[1725:1725:0324/120302:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[1725:1725:0324/120302:VERBOSE1:component_updater_service.cc(286)] CrxUpdateService stopping
[1725:1727:0324/120302:VERBOSE1:sandbox_ipc_linux.cc(122)] SandboxIPCHandler stopping.
.... [Edit: Note -- I'm appending what happens when I manually type in a web page name, below]
[12:12:0324/121659:VERBOSE1:sandbox_linux.cc(64)] Activated seccomp-bpf sandbox for process type: utility.
[12:12:0324/121659:VERBOSE1:child_thread.cc(245)] Mojo is disabled on child
[14:14:0324/121702:VERBOSE1:sandbox_linux.cc(64)] Activated seccomp-bpf sandbox for process type: renderer.
[14:14:0324/121702:VERBOSE1:child_thread.cc(245)] Mojo is disabled on child
[1839:1862:0324/121702:VERBOSE1:resource_loader.cc(241)] OnReceivedRedirect: http://www.yahoo.com/
[1868:1915:0324/121702:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[1868:1868:0324/121702:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[1868:1915:0324/121702:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[1839:1839:0324/121705:VERBOSE1:account_reconcilor.cc(98)] AccountReconcilor::Shutdown
[1839:1839:0324/121705:VERBOSE1:merge_session_helper.cc(212)] MergeSessionHelper::CancelAll
[1839:1839:0324/121705:VERBOSE1:account_reconcilor.cc(74)] AccountReconcilor::~AccountReconcilor
[1839:1839:0324/121705:VERBOSE1:ipc_sync_channel.cc(386)] Canceling pending sends
[1839:1839:0324/121705:VERBOSE1:component_updater_service.cc(286)] CrxUpdateService stopping
****Edit: Note ... histograms would normally follow, but I truncated it.
So, anyone have an idea of how to figure out and repair the problem ?
I've never had bluetooth, so I don't think installing those libs will help.
But I am stumped and frustrated, there's no obvious error message clue as to what might be causing the problem, just some esoteric mention of "mojo" diabling without indication of whether that's even good or bad, and the fact that just about everything is shutting down and cancelling everything.... for no reason...
I solved the problem.
Running DMESG, I found a warning that an instruction exception had happened from Google Chrome. That's how I was able to figure out that the kernel processor configuration had somehow changed the memory management algorithms during my recompile.
I am using kernel 3.18.25, and I think it was specifically the "Processor Type and features -> Transparent Hugepage Suport" that caused the problem. Hugepage support must be set to "madvise" rather than to "always" in order for Chrome to work. I suspect the reason Chrome fails, is that the kernel call fails even though the memory is allocated when it is set to always. Some other people on the web reported a similar issue in obscure Google forums lists, so I'm just confirming that it is the most likely culprit.
Just in case that is not the only option which caused Google Chrome to fail, here are the kernel options which I tinkered with between the time I discovered the AW snap problem, and when the problem was solved.
I am listing only the options that I turned on, or changed the value of in that period of time. The rest of the unlisted options that deal with memory management, are all "off".
Processor Types and Features -> Linux guest support: (enable)
Enable paravirtualization, Paravirtualization layer for spinlocks, Xen guest support, Support for running as PVH guest, KVM Guest support, Paravirtualization steal time accounting.
Processor Types and Features -> Support Intel Processors, Support AMD processor
Processor Types and Features:
Enable 1GB pages for kernel pagetables.
Numa Memory allocation and Scheduler support:
ACPI NUMA detection (only),
6 (Maximum Numa nodes as a power of 2),
Sparse Memory virtual memmap,
Enable to assign a node which has only movable memory,
enable for balloon memory compaction,
page migration,
Enable KSM for page merging,
(4096) Low address space protect from user allocation,
Transparent Hugepage support (madvise),
Continuguous memory allocator,
(7) maximum count of the CMA areas,
MTRR support, cleanup support,
MTRR cleanup enable value (1),
MTRR cleanup spare reg num (1),
Enable seccompt to safely compute untrusted byte code.
Try to start it as chromium --no-sandbox - worked for me (but then I guess my kernel somewhat misconfigured)
Related
I am using BigBlueButton with canvas. I installed it using the script provided on their Github page, namely:
wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -w -a -v xenial-22 -s bbb.example.com -e info#example.com
The problem is whenever I create a conference and join it. I couldn't use the audio neither listening.
When clicking on join with microphone, an error pops-up saying:
Failure on call (reason=ICE error) (error 1004)
And when I click on the Listen only, nothing happens.
I consulted the logs but nothing useful, I suspected some sound errors due to host configuration but I am not able to get things clear. Maybe some of you could have an idea about which logs to consult.
I suspect it is a problem related to FreeSWITCH, I followed a setup here about setting up FreeSWITCH with a firewall (even though I don't use a firewall but BBB config indicates that it considers a firewall) but nothing changed.
Any suggestion would be appreciated.
In my case I fixed this by commenting the line containing (voiceBridge=...) In app/models/bigbluebutton_conferenfe.rb.
You saved my life. The file younes is talking about is from Canvas LMS. If you followed the official installation instructions, this file should be in /var/canvas/app/models/big_blue_button_conference.rb. You will need to restart the application (or if you don't know how, the server) for the change to take effect.
The line to comment in context:
current_host = URI(settings[:default_return_url] || "http://www.instructure.com").host
send_request(:create, {
:meetingID => conference_key,
:name => title,
# :voiceBridge => format("%020d", self.global_id),
:attendeePW => settings[:user_key],
:moderatorPW => settings[:admin_key],
:logoutURL => (settings[:default_return_url] || "http://www.instructure.com"),
:record => settings[:record] ? "true" : "false",
:welcome => settings[:record] ? t("This conference may be recorded.") : "",
"meta_canvas-recording-ready-user" => recording_ready_user,
"meta_canvas-recording-ready-url" => recording_ready_url(current_host)
}) or return nil
I am doing a lookup operation Couchbase Java SDK 3.0.9 which looks like this:
// Set up
bucket = cluster.bucket("my_bucket")
collection = bucket.defaultCollection()
// Look up operation
val specs = listOf(LookupInSpecStandard.get("hash"))
collection.lookupIn(id, specs)
The error I get is BUCKET_NOT_AVAILABLE. Here are is the full message:
com.couchbase.client.core.error.UnambiguousTimeoutException: SubdocGetRequest, Reason: TIMEOUT {"cancelled":true,"completed":true,"coreId":"0xdb7f8e4800000003","idempotent":true,"reason":"TIMEOUT","requestId":608806,"requestType":"SubdocGetRequest","retried":39,"retryReasons":["BUCKET_NOT_AVAILABLE"],"service":{"bucket":"export","collection":"_default","documentId":"export:main","opaque":"0xcfefb","scope":"_default","type":"kv"},"timeoutMs":15000,"timings":{"totalMicros":15008977}}
The strange part is that this code hasn't been touched for months and the lookup broke out of a sudden. The CB cluster is working fine. Its version is
Enterprise Edition 6.5.1 build 6299.
Do you have any ideas what might have gone wrong?
Note that in Couchbase Java SDK 3.x, the Cluster::bucket method returns instantly, and continues opening a bucket in the background. So the first operation you perform - a lookupIn here - needs to wait for that resource opening to complete before it can proceed. It looks like it took a little longer to access the Couchbase bucket than usual and you got a timeout.
I recommend using the Bucket::waitUntilReady method after opening a bucket, to block until the resource opening is complete:
bucket = cluster.bucket("my_bucket")
bucket.waitUntilReady(Duration.ofMinutes(1));
This problem can occur because of firewall. You need to allow these ports.
Client-to-node
Unencrypted: 8091-8097, 9140 [3], 11210
Encrypted: 11207, 18091-18095, 18096, 18097
You can check more from below
https://docs.couchbase.com/server/current/install/install-ports.html#_footnotedef_2
We are running a Sails.js API on Google Container Engine with a Cloud SQL database and recently we've been finding some of our endpoints have been stalling, never sending a response.
I had a health check monitoring /v1/status and it registered 100% uptime when I had the following simple response;
status: function( req, res ){
res.ok('Welcome to the API');
}
As soon as we added a database query, the endpoint started timing out. It doesn't happen all the time, but seemingly at random intervals, sometimes for hours on end. This is what we have changed the query to;
status: function( req, res ){
Email.findOne({ value: "someone#example.com" }).then(function( email ){
res.ok('Welcome to the API');
}).fail(function(err){
res.serverError(err);
});
}
Rather suspiciously, this all works fine in our staging and development environments, it's only when the code is deployed in production that the timeout occurs and it only occurs some of the time. The only thing that changes between staging and production is the database we are connecting to and the load on the server.
As I mentioned earlier we are using Google Cloud SQL and the Sails-MySQL adapter. We have the following error stacks from the production server;
AdapterError: Invalid connection name specified
at getConnectionObject (/app/node_modules/sails-mysql/lib/adapter.js:1182:35)
at spawnConnection (/app/node_modules/sails-mysql/lib/adapter.js:1097:7)
at Object.module.exports.adapter.find (/app/node_modules/sails-mysql/lib/adapter.js:801:16)
at module.exports.find (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:120:13)
at module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:163:10)
at _runOperation (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:408:29)
at run (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:69:8)
at bound.module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/basic.js:78:16)
at bound [as findOne] (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21)
at Deferred.exec (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:501:16)
at tryCatcher (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/util.js:26:23)
at ret (eval at <anonymous> (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/promisify.js:163:12), <anonymous>:13:39)
at Deferred.toPromise (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:510:61)
at Deferred.then (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:521:15)
at Strategy._verify (/app/api/services/passport.js:31:7)
at Strategy.authenticate (/app/node_modules/passport-local/lib/strategy.js:90:12)
at attempt (/app/node_modules/passport/lib/middleware/authenticate.js:341:16)
at authenticate (/app/node_modules/passport/lib/middleware/authenticate.js:342:7)
at Object.AuthController.login (/app/api/controllers/AuthController.js:119:5)
at bound (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21)
at routeTargetFnWrapper (/app/node_modules/sails/lib/router/bind.js:179:5)
at callbacks (/app/node_modules/sails/node_modules/express/lib/router/index.js:164:37)
Error (E_UNKNOWN) :: Encountered an unexpected error :
Could not connect to MySQL: Error: Pool is closed.
at afterwards (/app/node_modules/sails-mysql/lib/connections/spawn.js:72:13)
at /app/node_modules/sails-mysql/lib/connections/spawn.js:40:7
at process._tickDomainCallback (node.js:381:11)
Looking at the errors alone, I'd be tempted to say that we have something misconfigured. But the fact that it works some of the time (and has previously been working fine!) leads me to believe that there's some other black magic at work here. Our Cloud SQL instance is D0 (though we've tried upping the size to D4) and our activation policy is "Always On".
EDIT: I had seen others complain about Google Cloud SQL eg. this SO post and I was suspicious but we have since moved our database to Amazon RDS and we are still seeing the same issues, so it must be a problem with sails and the mysql adapter.
This issue is leading to hours of downtime a day, we need it resolved, any help is much appreciated!
This appears to be a sails issue, and not necessarily related to Cloud SQL.
Is there any way the QPS limit for Google Cloud SQL is being reached? See here: https://cloud.google.com/sql/faq#sizeqps
Why is my database instance sometimes slow to respond?
In order to minimize the amount you are charged for instances on per use billing plans, by default your instance becomes passive if it is not accessed for 15 minutes. The next time it is accessed there will be a short delay while it is activated. You can change this behavior by configuring the activation policy of the instance. For an example, see Editing an Instance Using the Cloud SDK.
It might be related to your policy setting. If you set it to ON_DEMAND, the instance will sleep to save your budget so that the first query to activate the instance is slow. This might cause the timeout.
https://cloud.google.com/sql/faq?hl=en
In developing in Fi-Cloud's CEP I've been having an issue that has been happening repeatedly. As I'm trying to develop a definition to perform a task, CEP's server and Authoring Tool stop responding, although ssh is still responsive.
This issue happens as I develop. I'm using the AuthoringTool to alter the definition bit by bit and then I re-upload it to the server through the authoring tool's export feature.
To reinitiate the proton with the new definition each time I alter it, I use Google's Postman with this single operation:
-PUT (url:http://{ip}:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer)
header: 'Content-Type' : 'application/json'; body : {"action": "ChangeDefinitions","definitions-url" : "/ProtonOnWebServerAdmin/resources/definitions/Definition_Name"}
At the same time, I'm logged in with three ssh intances, one to monitor the files being created on /opt/tomcat10/sample/ and other things, and the other two to 'tail -f ' log files the definition writes to, as events are processed: one log for events recieved and another log for events detected by the EPAgent.
I'm iterating through these procedures over and over as I'm developing and eventualy CEP server and the Authoring Tool stop responding.
By "tailing" tomcat's log file (# tail -f /opt/tomcat10/logs/catalina.out) I can see that, when under these circumstances, if I attemp a:
-GET (url: http://{ip}:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer)
I get no response back and tomcat logs the following response:
11452100 [http-bio-8080-exec-167] ERROR org.apache.wink.server.internal.RequestProcessor - An unhandled exception occurred which will be propagated to the container.
java.lang.OutOfMemoryError: PermGen space
Exception in thread "http-bio-8080-exec-167" java.lang.OutOfMemoryError: PermGen space
Ssh is still responsive and I can look at tomcat's log this way.
To get over this and continue, I exit ssh connections and restart CEP's instance in the Fi-Cloud.
Is the procedure I'm using to re-upload and re-run the definition inapropriate? Should I take a different approach to developing?
When you update a definition that the CEP is already working with, and you want the CEP engine to work with the updated definition, you need to:
Export the definition using the authoring tool export (as you did)
Stop the engine run, using REST PUT
PUT //host:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
{"action":"ChangeState","state":"stop"}
Start the engine, using REST PUT
PUT //host:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
{"action":"ChangeState","state":"start"}
You don't need to activate the "ChangeDefinitions" action, since it is the same definition name that the engine is already working with.
Activating "ChangeDefinitions" action, only influences the next run of the CEP, and has no influence on the current run.
This answer your question about how you should update a CEP definition.
Hope it will solve your issue.
We've been getting a 503 error since yesterday when making this call:
result = session.execute(
api_method: drive.files.insert,
body_object: file,
media: media,
parameters: {'uploadType' => 'multipart', 'alt' => 'json'}
)
We have 3 set of keys - one each for our development, staging, and production environments.
The above call works without issue in our development environment, but fails 100% of the time in both staging and production environments
Based on the gists shared privately, it looks like the issue is the user agent header. I was able to reproduce by setting the UA similar to that one. I haven't been able to narrow it down to a particular issue with the UA, just that it doesn't work. Other multi-line strings work, and other chars seem fine if I replace the newlines.
Anyway, easiest thing to do is set :application_name with a different value that what you're using now.