Xvfb is frozen about headless HOT 25 CLOSED

Does it work with a different screen number, such as /opt/X11/bin/Xvfb :66636 -screen 1 1280x1024x24 -ac ?

from headless.

I'll need to check it when I run into this problem again.
I changed the port as it was my first guess and it didn't work, but I didn't try to change the screen number.

from headless.

It didn't.

➜  ✗ /opt/X11/bin/Xvfb :66636 -screen 0 1280x1024x24 -ac
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
(EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
➜ ✗ /opt/X11/bin/Xvfb :66636 -screen 1 1280x1024x24 -ac
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet6
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for inet
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
(EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
➜  ✗ /opt/X11/bin/Xvfb -screen 1 1280x1024x24 -ac
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
_XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
^C⏎                                                                                                                                                                                                                                                                                        ➜  ✗

from headless.

have same problem. any ideas?

from headless.

Did you found any solution?

from headless.

I have found solution. in my case I was lunching multiple instances of browser in single display of Xvbf.
It seems one instance of browser run in display №100 and second instance cound't access to that display.

my solution is running Xvfb display per browser instance and it solved my problem

from headless.

My solution is to run those three commands on first post whenever this happens. =/

from headless.

Thank you @ajahongir . Seems like I have the same issue.
@bpinto Thank you too (:

from headless.

Hello,

I have same issue:
/usr/local/share/gems/gems/headless-1.0.1/lib/headless.rb:156:in `ensure_xvfb_is_running': Xvfb is frozen (Headless::Exception)

I start headless via the following command:
headless = Headless.new(autopick: true, reuse: false, destroy_at_exit: true).start

Why does it get frozen sometimes?
Restarting the server solves the problem, but it is not a viable solution for the production server.

Please advise.

Thanks,
-Andrey

from headless.

@WebmasterA I think when you start a Headless on some port some times it doest get ready to use.
try dont start a new instance of headless every time. instead you have to start once and use that process every time. you will same some time to creating a new instance:
Headless.new(destroy_at_exit: false, reuse: true).start

from headless.

@WebmasterA
Hello,

In my case I didn't close the browser instance and tried to open new one. Also I recommend to recreate headless when you're closing the browser to ensure there are no unclosed browser instances.
Please let me know if you will find a better solution.

from headless.

@yuri-karpovich I prefer to close browser instance every time because it may cause to memory leak on server and not close headless.

from headless.

Thanks for the quick reply guys.

I do close the browser every time.

I open the browser with:

client = Selenium::WebDriver::Remote::Http::Default.new
client.timeout = 600 # seconds - default is 60
d = Selenium::WebDriver.for :chrome, :prefs => prefs, :http_client => client, :switches => %w[--disable-popup-blocking --disable-translate]
b = Watir::Browser.new d

At the end of the script I close it with:

b.close

If my script fails I rescue and close with:
rescue => e
puts "Error: #{e}"
b.close
exit
end

from headless.

@ajahongir This script will eventually need to handle 100+ automations. Therefore I cannot assign an open port to each one of them and keep them opened. That is why I:
autopick: true - each time different
reuse: false - so they do not crash into each other
destroy_at_exit: true - they I can use ports that has been used previously.

Am not properly understand how this logic suppose to work?

Thanks,
-Andrey

from headless.

@ajahongir yes, I mean the same - of course I close browser. Also I close destroy headless when it acceptable.

from headless.

Here is a question for you guys:

I do not do headless.destroy
Should I be doing that?
Assuming I have multiple scripts running at the same time with
headless = Headless.new(autopick: true, reuse: false, destroy_at_exit: true).start

Do I need to do headless.destroy?

Here is a little note about my script:
After my Ruby script finished downloading the files, it calls Perl script via system call. The order is the following:
download files...
b.close
system("perl dostuff.pl")

Thanks,
-Andrey

from headless.

Unfortunately I'm not a pro with headless. The only idea I have that parallel scripts are trying to use the same session. Rubydoc says:

Cucumber with wkhtmltopdf
Note: this is true for other programs which may use headless at the same time as cucumber is running

When wkhtmltopdf is using Headless, and cucumber is invoking a block of code which uses a headless session, make sure to override the default display of cucumber to retain browser focus. Assuming wkhtmltopdf is using the default display of 99, make sure to set the display to a value != 99 in features/support/env.rb file. This may be the cause of Connection refused - connect(2) (Errno::ECONNREFUSED).

headless = Headless.new(:display => '100')
headless.start

from headless.

@WebmasterA

Do I need to do headless.destroy?

if you use destroy_at_exit=true its ok.

I prefer to do this:

client = Selenium::WebDriver::Remote::Http::Default.new
driver = Selenium::WebDriver.for :chrome, client: client
browser = Watir::Browser.new driver
system("perl dostuff.pl")
rescue
puts 'Error'
ensure
browser.close
end

from headless.

@WebmasterA did you found a solution?

from headless.

I encountered this error as a thundering-herd problem while trying to spin up a large number of Headless sessions concurrently (in different processes). The Headless sessions were timing out while trying to find a display to use - they were each starting at :99, then :100, etc., but it was taking too long for them to count up to an available display.

I fixed the issue with a very simple initializer:

# monkeypatch to fix a thundering-herd problem associated w/ Xvfb startup
# test the possible displays in a random order, instead of from the start, every time
class Headless

private

  def attach_xvfb
    possible_display_set = @autopick_display ? @display..MAX_DISPLAY_NUMBER : Array(@display)
    pick_available_display(possible_display_set.to_a.shuffle, @reuse_display)
  end

end

I am happy to put this into a pull-request if @leonid-shevtsov is amenable - it's a little more complicated than just copying the code over, as it breaks a whole bunch of tests that assume we're always looking for display :99.

from headless.

I encountered the same error and was able to reproduce it.
This error in my case was coming when the Xvfb process is still running but the lock file gets deleted somehow.
So the next time you do Headless.new it will try to launch new Xvfb by calling launch_xvfb which will fail giving below error because Xvfb is already running (Output of running Xvfb command /usr/bin/Xvfb :99 -screen 0 1280x1024x24 -ac)

_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE)
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)

The above Xvfb command will fail and not create the new lock file and will also skip the "Xvfb did not launch - something's wrong" exception because "unless result" will be false. So ensure_xvfb_is_running will keep on failing the xvfb_running? test because of missing lock file and at last will throw "Xvfb is frozen" after XVFB_LAUNCH_TIMEOUT

Hope this might help somebody having the same scenario.

from headless.

I made some changes that should fix or at least help debug this problem. Please upgrade to headless version 2.0.0 and see if the issue persists.

from headless.

Hey @leonid-shevtsov, could you point me to the commit that solved this problem? The node version of headless is seeing the same issue (here).

from headless.

@paulkernfeld There's a node version of headless? Wow, didn't know that!

Here's the commit - IIRC the change was to start Xvfb with Process.spawn 2886098

from headless.

When I've got this error, my issue was that I was logging in through a Putty session that had X11 forwarding enabled. When I changed this setting, I could successfully start the Xvfb server.

from headless.