We have automated tests that require runnable Google Chrome. Yet the Google Chrome kept crashing.
The first encountered is:
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
This one is easy, install
mesa-dri-drivers solved this.
ERROR:sandbox_linux.cc(338)] : InitializeSandbox() called with multiple threads in process gpu-process
My initial guess was SELinux, but journalctl returns nothing about it. After a few hours, I thought, how about firefox? Maybe it helps to set the SELinux and install the missing dependencies? And… Tada, both Firefox and Google Chrome worked. Eventually, I dug out that Google Chrome requires fonts to works. Specifically,
To sum up, following command worked for me:
sudo yum -y install mesa-dri-drivers liberation-fonts-common liberation-sans-fonts
Update for ChromeDriver user
If you are also use ChromeDriver. Be aware that ChromeDriver 2.31 and up requires
libc.so.6(GLIBC_2.18), yet RHEL 7 only provide
clamdscan is much faster to run than
clamscan, however, it requires
clamd which is a bit harder to setup, so I have some tips for troubleshooting:
ERROR: Could not lookup : Servname not supported for ai_socktype
Usually you should check the permission, especially whether the current user is in group
clamscan (the primary group of the clamd running user).
lstat() failed: Permission denied. ERROR
This is usually because
clamd running does not have the permission to run the is run as non-root user.
So you will need to enlist User
clamscan (the user that runs
clamd). You need to logout and login to make that change effective.
If it is still failed with the same error messsage, it is still possible that you are fooled by ACL permission. Use
getfact to check it. The reason? When you
ls, you get:
drwxr-xr-x+ 2 testuser testuser 40 Jul 17 15:19 /tmp/test
But your actual ACL (
getfacl /tmp/test)might look like:
getfacl: Removing leading '/' from absolute path names
# file: tmp/test
# owner: testuser
# group: testuer
The Clamav image is from http://www.stepbystep.com/how-to-integrate-clamav-into-pureftpd-for-virus-scanning-on-debian-squeeze-45061/
- Paste the RSA private key (e,g. content of ~/.ssh/id_rsa) to Jenkins, like this:
- Ensure the
~/.ssh/known-hosts in Jenkins master has agent/slave host key. Like:
stdbuf -o0 -e0 ssh-keyscan -H &>> ~/.ssh/known_hosts
- Ensure the
~/.ssh/authorized_keys of Jenkins agent/slave has Jenkins master’s RSA key.
- (Optional) if you can access the terminal of Jenkins master, test the connection by using:
Because the issue Presence of ECDSA SSH keys breaks SSH credentials plugin seems to affect the Jenkins masters that have both ECDSA and RSA.
I have encountered the following error message when I was trying to connect Jenkins slave after plugin update:
[SSH] WARNING: No entry currently exists in the Known Hosts file for this host. Connections will be denied until this new host and its associated key is added to the Known Hosts file.
Key exchange was not finished, connection is closed.
java.io.IOException: There was a problem while connecting to xxx.xxx.xxx.xxx:22
I have tried to connect using
ssh in console, it connected successfully, but Jenkins still refuse to connect.
Then I discovered that, if I provided the RSA Host key, Jenkins can now connected to slaves.
I guess the reason is ssh just use the known host key to determine whether it is known, and be able to fallback to RSA for actual authentication. On the other hand, Jenkins does not seem to have the fallback. You given RSA identity, then Jenkins expect RSA in
The issue is already filed as JENKINS-42959 Failed known_hosts verification for SSH agent. In the meantime you can use following workaround:
stdbuf -o0 -e0 ssh-keyscan -H <host> &>> ~/.ssh/known_hosts
stdbuf here is for printing the stdout and stderr as the order of time they appear, just like what you would see in console. Otherwise the stderr will go first and then stdout.
When I run
on my newly setup docker in Fedora 21, it shows:
FATA Get http:///var/run/docker.sock/v1.16/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
The problem resolve after I re-login. So the error seems like that the permission is not yet applied, as I just add myself to docker group without logout.
So, if you cannot or don’t want logout just yet, use
sg docker "docker <subCommand> ..."
As long as you are in docker group in /etc/group, sg won’t ask you password.