I'd like to run xvfb on Heroku. On my mac, I used the dmg to install it. Would anyone have any idea how to go about this on Heroku?
I came across these buildpacks (http://github.com/douglasjsellers/heroku-xvfb-buildpack) - but following the instructions didn't seem to solve the problem as xvfb is still not installed properly. Also, I tried installing the xvfbwrapper (https://pypi.python.org/pypi/xvfbwrapper/0.1.0), but it's still not working on Heroku (apologies for what is potentially a noob question).
Here is the error I get in my logs off of Heroku:
2015-02-24T02:09:16.035298+00:00 app[web.6]: cmd=['Xvfb', '-help']
2015-02-24T02:09:16.035564+00:00 app[web.6]: Program install error!
2015-02-24T02:09:16.035302+00:00 app[web.6]: OSError=[Errno 2] No such file or directory
Here is the code:
temp = tempfile.mkstemp(suffix='.html')
html = os.fdopen(temp[0], "r+")
html.write(cv)
html.seek(0, 0)
display = Display(visible=0, size=(800, 600))
display.start()
# Open the file on Selenium to load the JavaScript
driver = webdriver.Firefox()
driver.get("file://" + temp[1])
I found this question while researching how to update Xvfb for Cedar-14, and I managed to get #2 to work. So here's how:
I used buildpack-apt to install x11-xkb-utils xvfb x11-xkb-utils xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic libxfont1 xvfb.
After running the apt buildpack, you need to patch Xvfb a bit to make everything work smoothly. For that, I used my own run-bash buildpack, but everything that lets you run a bash script during Heroku compile will work. Here's the script I used to patch Xvfb and index the fonts: https://gist.github.com/fxtentacle/960cdb96ece01add8686
Now you can use heroku run bash to check with XAUTHORITY=/tmp/xvfb-run.2NG0xl/Xauthority Xvfb ":99" -screen 0 1280x1024x24 -nolisten tcp that the Xvfb is working.
Yes, it is possible, but complicated. I followed some of what fxtentacle did (in their answer), but this may be simpler. These instructions provide for a minimal Xvfb setup; it still prints out a bunch of warnings.
Use heroku-buildpack-apt to install the xvfb and libnotify4 debian packages. Then use this buildpack to fix the /usr/bin/xkbcomp issue:
https://github.com/captain401/heroku-buildpack-xvfb
Then you can use xvfb-run $PROGRAM to run your application.
I'm wondering the same thing. Seems like you already found this guy's issue. All the buildpacks mentioned are 1+ years old, and don't work anymore.
Two viable seeming options:
Compile a self-contained xvfb binary a la https://github.com/kenshin23/xvfb-portable-binary that runs on Heroku's current OS and architecture, rebuild when they update.
Install all dependencies from the apt package manager into someplace like ~/.apt, and run from there, as in the latest buildpack-apt. For me, this option dies with sh: 1: /usr/bin/xkbcomp: not found. Xvfb is looking in /, while apt installed the command to ~/.apt/usr/bin/xkbcomp. Haven't figured out how to tell Xvfb to look in ~/.apt/.
Related
I cant install heroku in my kali linux operating system. how can i resolve this issue?
isn't it not possible to run heroku in kali linux?
when I have try to install, it show snap command not found.
Heroku no longer supports Snap installs:
Snap installs are no longer supported. Please use another install method below.
Since Kali is derived from Debian, you should be able to use the Debian / Ubuntu method (which doesn't auto-update) or the standalone tarball method (which does). You can also use the NPM / Yarn package if you prefer, though Heroku recommends against it.
All of these options require some amount of trust in Heroku. The first two pull a script down from the Internet and pipe it into sh, which always makes me a bit uneasy. I suspect they both request elevated privileges during the install process. Instead of piping the file directly in to sh as Heroku recommends, I suggest you download it and at least give it a quick read through the first time.
In any case, here is the command that Heroku recommends to install the standalone version:
curl https://cli-assets.heroku.com/install.sh | sh
I have a GUI application that I would like to set up testing for via GitHub Actions. I already have it set up so that GitHub Actions compiles the application on Ubuntu, but now what I would like to do is run the application for a few seconds and test if it crashes or not. However, currently it fails to start because there is no X11 server installed.
Is there a way that I can install a dummy X11 server, so that the application runs? I don't care about what is actually displayed, I just want the application to be able to open without failing due to the X11 server missing.
Alternatively, is there a way to install a dummy Wayland server? This app can also run on Wayland.
I use this command:
linux:
runs-on: ubuntu-latest
steps:
run: |
export DISPLAY=:99
sudo Xvfb -ac :99 -screen 0 1280x1024x24 > /dev/null 2>&1 &
mycommand
You can try xvfb-run from Xvfb project. It starts your application(s) under fully compatible X Window server w/o any hardware (you can even run x11vnc among your apps and connect to the server over VNC, but I believe it's not your case for now). Personally I use xvfb-run for isolated screenless X.org-aware packages build, when, e. g., a package needs to take a snapshot of itself while making documentation.
$ xvfb-run x.org_application_binary
Yes, that is possible. Simply create a Docker Image with your X11 environment and deploy your application in it.
Alternatively, you can also just install X11 on your machine. Make sure to do it in every run, as the environments always fully reset:
sudo apt-get install xorg openbox
We started seeing some strange errors in our logs that normally appear when ruby isn't compiled properly with OpenSSL. But it's inconcistent...
We're getting errors like:
RuntimeError: Unsupported digest algorithm (SHA256). (also with other digests, like sha1). example error trace
Faraday::SSLError (SSL_CTX_new: (null)) example error trace
We managed to reproduce it when starting unicorn using service unicorn start or systemctl start unicorn. But only with some requests... Not all of them. Some requests that use OpenSSL under the hood do work. Others don't.
However, when we start unicorn with /etc/init.d/unicorn start, everything works without a hitch. (to clarify, systemd starts the same /etc/init.d script)
We tried debugging ENV vars, user permissions, file/dir ownership, recompile ruby, bootstrap a new server from scratch... Nothing seems to help.
In case this helps:
unicorn init.d script
unicorn.rb
What are we missing? What can we try that we haven't thought of?
UPDATE 1
output of some debug commands, e.g. OpenSSL, ruby etc
PATH is being set inside the init.d script
unicorn is being executed via su into www-data user
The same problem happens when we use this unicorn.service file in /etc/systemd/system
We're running Ubuntu 16.04 on Gcloud
Ruby was not installed via apt (explicitly removed, in case platform came pre-installed) and compiled from scratch. We're currently running 2.3.4 and tried also 2.3.6. Compiled either manually or using ruby-build. No rbenv, nor RVM.
We install libssl-dev via apt (we're running apt-get install -y autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev before building ruby)
UPDATE 2
We're using a scripted/repeatable build process for the VM (using fabric), and this problem is consistent on multiple VMs we bootstrapped on GCloud. We then tried a VM on DigitalOcean with the same bootstrap scripts, and the problem doesn't seem to appear there.
In both cases we picked Ubuntu 16.04 64bit base image, but obviously there are some differences with kernel versions, base installed packages etc...
UPDATE 3
The problem simply vanished. See my answer below.
#gingerlime I had a similar situation with our Jenkins on GCP, we're using ChefDK 3.1.0 (ruby embeed 2.5.1p57) -- tried other also, over a Jenkins that was running over systemd (Ubuntu 16.04) and upstart (Ubuntu 14.04) -- we tried on both versions, right now running over 16.04 in 4.15.0-1023-gcp kernel version, running a few jobs with kitchen-docker and this problem always emerge in a few situations.
I digged into and found that this only happens when the Etc.getlogin class gets called (for me here), this doesn't return any error, it return the correct info, the correct type of the class (String), but once it gets a call, the Unsupported digest algorithm gets raised.
If I start the process manually by root or jenkins user, this problem doesn't happen. I tried to implement the Etc.getlogin in several different ways, like using ENV['USER'], a fixed String, or other classes from Etc, like getpwuid, simulating the return class and values from Etc.getlogin, and the error doesn't get raised.
I'm not sure if this is some bug related to the ruby version and the custom kernel that GCP instances uses, but it happens in a similar situation like yours, and for me, the Etc.getlogin was the problem. Right now, I fixed by using a custom configuration that doesn't gets the call from this function, and it's working normally.
One option is that this isn't an issue of sysVinit vs systemd at all, but you just haven't triggered the issue with your sysVinit script yet.
When you run your svsVinit script through the systemctl command it's going through a compatibility layer, and there may be a problem there. Your problem would be simplified both yourself and for us if you reproduced the issue directly with a systemd service file and shared that file.
You mentioned debugging ENV, but didn't mention exactly what you checked in the ENV. This is definitely one place where systemd could make a difference. As seen in man systemd.exec, systemd sets $PATH in the environment to a fixed value:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
If this is not exactly the same as when run directly as an sysVinit script, that could be an issue.
I would also check for all your copies of SSL on the system. Do you have more than one? Where? Do you have more than copy of the ruby openssl module loaded?
locate -r lib/.*libssl.*so
Also see the answer to the FAQ: Why do things behave differently under systemd?
(also posted on this github issue)
It looks like the problem just vanished. We were testing and reproducing it consistently, across several Compute Engine instances on Google Cloud. Under certain conditions (unicorn / puma started by systemd, etc), it was completely reproducible both with our own rails app, and with a plain vanilla rails app we've set for testing purposes. It was reproducible across several ruby versions as well (we tested 2.3.4, 2.3.6 and 2.5.0).
Suddenly, all instances that were consistently failing started working without exhibiting these problems. Like it never existed. We didn't even reboot some of those instances, and we saw no evidence of any unattended upgrades taking place... We also had one snapshot of a system that had this problem, and that we can reliably reproduce on. Creating an instance from this snapshot stopped exhibiting it as well from that specific point in time a few hours ago.
We're totally confused as to what might have cause it, and what might have made it disappear... However, without being able to reproduce it now, I guess there's no point leaving this issue open, so will close it. Chalk it up to Deus ex machina I suppose. (perhaps the google support gods, but they haven't reported anything back to us yet)
I am trying to get a virtual machine working with Vagrant. Everything seems to run fine and it begins to unpack/install all the needed files. But every single time it just stalls when I get to this point.
==> default: Setting up grub-pc (2.02~beta2-36ubuntu3.11) ...
Here is a screen shot of what is going on:
I shut down the virtual machine and booted it back up. I can ssh into it but nothing seems to work. By this I mean there is no psql, no SQLAlchemy. These, among other things, are supposed to be set up in the VM. It seems as if it halts before installing the necessary software.
I've tried vagrant destroy and reinstalling, downloading a new image in case that one was corrupt and I tried reinstalling Vagrant. I am running Vagrant 1.9.5
Looks like you're provisioning with shell commands. I'm guessing that there's some sort of install prompt that's coming up and demanding some sort of user interaction / response. Because vagrant's handling the provisioning behind the scenes, you can't respond to the prompt and the install is not continuing.
You should be able to fix the issue by editing your Vagrantfile. As a guess, it looks like grub-pc is causing the issue (there's actually a grub-pc command prompt in the image you shared). See if you can figure out which package is installing grub-pc. If you're lucky, the problem can be solved by piping in a yes along with the install command (which will automatically answer yes to all install questions). This looks something like yes | sudo apt-get install grub-pc. If grub-pc is being installed as part of another package, you'll need to do some educated guessing to figure out which package is installing it and adding the yes | apt-get pipe to that install line (or just add the pipe before every install line).
This being said, I ran into an issue when I was installing the Java SDK on vagrant, where Oracle was demanding I accept their terms of use before the install would complete and a yes pipe wouldn't solve the issue. I was able to fix it by searching the web for "silent java sdk install via command line". If you can figure out which package is causing the issue, and a yes pipe isn't enough, searching for how to "silently" install that package via command line should help.
UPDATE
As you can see in a comment on this answer
Unfortunately a yes pip didn't do the trick this time but a quick
search on how to "silently" install grub led me to this.
DEBIAN_FRONTEND=noninteractive apt-get -y -o
Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold"
upgrade . After editing my Vagrant file it worked perfectly
I get this error when I run my cucumber tests:
"*Unable to either launch or connect to Chrome. Please check that ChromeDriver is up-to-date. Using Chrome binary at: /opt/google/chrome/google-chrome (Selenium::WebDriver::Error::UnknownError)
*"
I downloaded the chromdriver, unzip it, copy it to the path (/opt/google/chrome/google-chrome ) and sudo chmod +x /opt/google/chrome/google-chrome.
which google-chrome : /usr/bin/google-chrome
which chromedriver : /usr/share/ruby-rvm/gems/ruby-1.9.2-p318/bin/chromedriver
capybara (1.1.2)
cucumber (0.9.4)
cucumber-rails (0.3.2)
selenium-webdriver (2.20.0)
I searched my error but none of the answers worked for me!
When I run my test I do not see chrome starts!
I really dont know what is wrong! I tried two different versions of chromedriver!
Jenkins should run/executes my tests in CI.The tests work when you run them but not when Jenkins runs them? I could run them by another user and then I installed jenkins and I get this error. I get the same error when I run my tests in terminal at terminal as well.Did you read https://wiki.jenkins-ci.org/display/JENKINS/My+software+builds+on+my+computer+but+not+on+Jenkins ? I couldnt find much about my problem here. xvfb: I installed the plugin in the jenkins but in the build environment if I click "run xvfb before the build and shut it down after", I get this error: "FATAL: null java.lang.NullPointerException"
Please provide more details. How does this question relate to Jenkins? Is Jenkins executing the tests? The tests work when you run them but not when Jenkins runs them? You do not go so far as to say that out loud, but I will assume it because it is what people usually need help with.
Did you read https://wiki.jenkins-ci.org/display/JENKINS/My+software+builds+on+my+computer+but+not+on+Jenkins ?
If you are executing Chrome inside a Jenkins job, do you have something like https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin or https://wiki.jenkins-ci.org/display/JENKINS/Xvnc+Plugin installed?
chromedriver can be installed in two ways: downloading, decompressing the zip and putting the file in "/usr/bin" or adding the "chromedriver-helper" gem in your Gemfile.
Choose one or another way because doing both many time it causes problems. If you are installing chromedriver from google, be sure to uninstall the gem:
gem uninstall chromedriver-helper
and be sure chromedriver is in your path:
which chromedriver
Give this a try instead => https://github.com/flavorjones/chromedriver-helper
Finally I found the answer:
if you want to run GUI tests on Jenkins CI running on Windows do not
configure it as a windows service instead run it from the command
prompt or set it up as a scheduled task to run on windows logon using
the command “java -jar jenkins.war”
taken from this article