Failed to open connection to "session" message bus: /usr/bin/dbus-launch terminated abnormally without any error message [duplicate] - selenium

I am using a very complex setup to test various non-public webpages. I use jenkins to run the python-selenium tests within a dockerimage. That way, I am completely independent of the jenkins environment and can create my own environment. In this environment I have the following software installed:
Ubuntu 16.04.3
Firefox: Mozilla Firefox 57.0.1
geckodriver: 0.18.0
nosetests: 1.3.7
selenium: 3.8.0
When running the tests, which mostly succeed, I see in the geckodriver.log output messages like
(firefox:55): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
/usr/bin/dbus-launch terminated abnormally without any error message
My questions:
What does this message mean?
Could that be an indication of the reason why sometimes the tests are failing?
If so, how to fix it?

The error you are seeing is :
(firefox:55): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
/usr/bin/dbus-launch terminated abnormally without any error message
So it is clear Firefox attempts to connect to D-BUS daemon and fails as dbus-launch gets terminated abnormally.
dbus-launch
dbus-launch is basically the utility to start a message bus by firefox through a shell script. It would normally be called from a user's login scripts. dbus-launch launches a session bus instance and print the address and pid of that instance to standard output.
You can read more about dbus-launch from the Linux man page
Root Cause
This error can arise if you use su (root), sudo, suedit, gksu. The main reason is DBUS_SESSION_BUS_ADDRESS retains its value when you su instead of picking up the value in /root/.dbus/session-bus.
Here you will find a detailed discussion on GConf Error: No D-BUS daemon running?! How to reinstall or fix?.
Another possible reason may be the base Firefox Browser version may be an older version on which updates were taken to reach the current version.
Solution :
There are a couple of solutions available to address this ubuntu related issue as follows :
Before you start Firefox you have to type export $(dbus-launch)
However this may result into another error with NSS_USE_SHARED_DB. So you have to use export NSS_USE_SHARED_DB=ENABLED as well.
The most convenient way would be to put all the configuration with in .bashrc file :
export $(dbus-launch)
export NSS_USE_SHARED_DB=ENABLED
firefox &
This discussion speaks about the solution in details.
If dbus-launch is not installed on your system you have to install dbus-x11 package which contains the dbus-launch program.
An effective solution would be to uninstall the older base version of Firefox Browser and install a recent released GA version of Firefox Browser.
Best Approach
The issue with dbus-launch was addressed properly by both Ubuntu and Mozila. To overcome this error you need to follow the below mentioned steps :
Keep your Ubuntu os updated with the Latest Patch Releases and updates.
Always use the latest released version of Selenium-Python client, WebDriver variant e.g. GeckoDriver and Web Browser, e.g. Firefox Browser.
Clean and Build the Project Workspace afresh through your IDE before and after executing your Test Suite.
Clear the Browser Cache before and after the execution of your Tests.
If you have to uninstall any of the Web Client variants (e.g. Mozilla Firefox) you can use Revo Uninstallar with Moderate Memory Scan so that the stale registry settings are discarded.
Use CCleaner tool regularly to wipe away the OS chores including the stale rust_mozprofile directories.

What does this message mean?
DBus is a message bus system for interprocess commutation. There is an open geckodriver issue on a similar if not the same subject:
request to geckodriver fails with no meaningful log entry when there is no access to $HOME/.mozilla or $HOME/.cache
Could that be an indication of the reason why sometimes the tests are failing?
The warning should not really affect the tests but it's difficult to speculate about your intermittent test failures without seeing what is actually happening in your tests.
If so, how to fix it?
Here are some things to try:
upgrade geckodriver to the latest stable version (currently 0.19.1)
update Firefox to the latest nightly version (currently 58)
try this answer
try this answer

For me the solution was to install dbus-x11
apt install dbus-x11

Related

Selenium chromedriver that does not depend on current Chrome installation

Due to organization policy, the Chrome browser installation on my Windows Server machine is automatically updated. I have some processes that rely on python Selenium and chromedriver. Because of this, my process breaks whenever my org decides to push out an update.
Is it possible to have chromedriver depend on some binary other than Chrome browser that will not be managed by my organization so that this doesn't happen?
Few of the workarounds to resolve the issue:
We have kept the chrome exe file in an artifactory and we download and install that particular chrome version every time before our execution through automation (our requirement is like that).
As #Corey is suggesting you can webdrivermanager, PFB link for more details
https://github.com/bonigarcia/webdrivermanager
You can try Dockerized Selenium, there you'll have the control in the docker-compose.yml file.

Firefox spontaneous launch in Selenium

Environment:
selenium-server-standalone-3.8.1.jar
geckodriver-v0.24.0
firefox 60.6.1
Everything was set up 6 months ago and everything worked well, the tests passed through the Selenium and there were no problems.
Since 08/23/2019 problems began. Without any launches test inside the Selenium process, started to run spontaneously browsers (firefox) and did not turn off.
These processes overload the processor on the server, after which the server starts to brake and also the site that is on the server. These "browser launches" continue until Selenium is reloaded by open browsers after which our automatic tests are blocked and display an error: "unable to create new native thread".
As soon as one such browser spontaneously opens, the processor load becomes 100%.
These browser launches occur approximately 1 time in 4-5 minutes.
All tests are disabled, but Selenium lives its own life, and continues to launch the browsers.
Maybe someone faced a similar problem? Any ideas why this is happening and how to fix it?
The launch of selenium occurs on command:
su screener -c "/usr/bin/java -Dwebdriver.gecko.driver=/usr/local/bin/geckodriver -jar /usr/lib/selenium/selenium-server-standalone-3.8.1.jar -enablePassThrough false -port 4444 >/var/log/selenium/selenium_std.log 2>/var/log/selenium/selenium_error.log &"
Term yourself lucky to have sailed smoothly with geckodriver-v0.24.0 and selenium-server-standalone-3.8.1.jar till 08/23/2019.
As per the documentation:
To work with geckodriver-v0.24.0 you need:
Selenium Python client version greater then 3.14
Firefox client version minimum 57 (which seems to be okay)
You can find the detailed GeckoDriver, Selenium and Firefox Browser compatibility chart in the discussion Which Firefox browser versions supported for given Geckodriver version?
Additional considerations
As a part of the best practices:
Upgrade JDK to recent levels JDK 8u222.
Upgrade Selenium to current levels Version 3.141.59.
Upgrade GeckoDriver to GeckoDriver v0.24.0 level.
GeckoDriver is present in the desired location.
GeckoDriver is having executable permission for non-root users.
Upgrade Firefox version to Firefox v65.0.2 levels.
Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
http://www.yourownlinux.com/2013/10/how-to-free-up-release-unused-cached-memory-in-linux.html) before and after the execution of your Test Suite.
If your base Web Client version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Web Client.
Take a System Reboot.
Execute your Test as a non-root user.
Always invoke driver.quit() within tearDown(){} method to close & destroy the WebDriver and Web Client instances gracefully.
You can find a detailed discussion in PhantomJS web driver stays in memory
If the stale WebDriver instances still persist you may require to forcefully remove them.
You can find a detailed discussion in Selenium : How to stop geckodriver process impacting PC memory, without calling driver.quit()?
Outro
Limit chrome headless CPU and memory usage

Does Chromium headless work on Windows Server Core 2016?

Background
I am tasked with replacing our IE based printing logic with Chromium so that we can eventually support running our current server software on Windows Server Core or potentially other operating systems that support .Net Core. My current thought is to either use Chromium embedded framework or to make use of Puppeteer. I am leaning towards the later because I feel it would be easier to port between operating systems.
Issue
Originally it failed to start with an error about sandboxing so I added the no-sandbox flag. Now when I try to load Chromium it fails to start with the exception below stating that it cannot load chrome.dll
PS C:\Program Files (x86)\Google\Chrome\Application>> .\chrome --headless --enable-logging --disable-gpu --screenshot="C:\screen.png" "https://www.chromestatus.com/"
Which yields the following error in the debug.log file:
[0813/133208.016:ERROR:main_dll_loader_win.cc(134)] Failed to load Chrome DLL from c:\Program Files (x86)\Google\Chrome\Application\68.0.3440.106\chrome.dll: The specified module could not be found. (0x7E)
I have checked around the internet and found a few mentions of this error but the suggested fixes don't seem to fix the issue.
I was able to download Chromium 72.0.3592.0 via Chocolatey and the issue is resolved in that version. I tested using Server Core 2016 LTSB.
choco install chromium --pre -y
chrome --headless --disable-gpu --dump-dom --enable-logging https://www.chromestatus.com/ --no-first-run
Edit:
If you are attempting to run Selenium Tests using Docker windowsservercore and chromium: The command line tests of chromium chrome.exe appear to never work from the container command line.
However when you run dotnet test app.csproj or dotnet vstest app.dll inside the container the webdriver successfully starts and drives the browser
This has been reported to the Chromium team. It appears that Chromium 68+ might have issues with Windows Server 2016.
https://bugs.chromium.org/p/chromium/issues/detail?id=873097

Selenium WDS executeScript()

I have a strange problem, which I'm unable to solve for sometime. I have a selenium WDS for Firefox browser. I tried to execute the code in JMeter UI, everything works fine. But when I try to execute the same in a server (using XVFB driver), I get the error:
rm="sun.org.mozilla.javascript.EvaluatorException: Can&apos;t find method org.openqa.selenium.remote.RemoteWebDriver.executeScript(string,org.openqa.selenium.remote.RemoteWebElement). (<Unknown source>#17) in <Unknown source> at line number 17"
All the required drivers are the same as the one I locally try. Yet, I get the error only when I run in the server but not locally. Please help
Most probably you have different versions of either WebDriver Sampler or dependency libraries, I don't see any other ways for the same script to work on one machine and don't work on another.
Install the same version of JMeter onto both machines (use JMeter 3.2 or later, whatever is available at JMeter Downloads Page)
Install latest version of the WebDriver Sampler plugin using JMeter Plugins Manager
Your test should now be running fine.

Running Selenium/PhantomJS inside a Vagrant box

I'm trying to set up testing for a Web app using behaving, which runs on top of behave and splinter - the latter of which in turn uses Selenium to drive PhantomJS. All of this is inside a VirtualBox-provided Vagrant box running CentOS 6.4. I've installed Selenium via pip, and I've installed PhantomJS from the Nux Dextop repo.
Trying to run my tests freezes Behave for 30 seconds, then raises:
selenium.common.exceptions.WebDriverException: Message: 'Can not connect to GhostDriver'
I think I've nailed it down to not being able to open a socket, and indeed, when I try to do this from the Python interactive shell, I can't open any socket to localhost at all. How do I get my tests to run?
I just had the same problem with the Can not connect to GhostDriver error. When trying phantomjs --help, I got the error
[WARNING] Unable to load library icui18n "Cannot load library icui18n: (libicui18n.so.48: cannot open shared object file: No such file or directory)"
After installing libicu48 (Ubuntu package), phantomjs --help gave me
[WARNING] phantomjs: cannot connect to X server
This made sense, since I didn't have an X server installed. Then, I discovered that phantomjs <= 1.4 requires an X server, but >= 1.5 is pure headless. So, instead of relying on my distro's phantomjs package, I installed it using npm, and now everything works fine.
I have installed the package of libicu48 and gnome-session-fallback for the bug.
$ sudo apt-get install libicu48 gnome-session-fallback