Category: Ubuntu

Codeship apt-get update errors and yarn and command returned a non-zero code 100

TL/DR: apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com (use with caution) may go a long ways in getting your build to work.

Some noteworthy things after learning about the interplay between codeship, docker, ubuntu apt-get, and the yarn package. This resolution may help with issues dealing with:

  • Invalid signatures with the yarn ubuntu package.
  • Errors running apt-get update
  • Errors updating the Dockerfile for a CodeShip build
  • Dealing with CodeShip build steps updates and cached steps

For now, I’m noting my crazy sequence of realizations in reverse order

A failed step on the server with CodeShip may not be very enlightening. If you see an apt-get install -y <some-package> returned a non-zero code: 100 error, you may need to run the step locally to see the full error using jet steps.

If you see the above error, it may be due to a command in your steps if the RUN command in the Dockerfile includes apt-get update -y

The apt-get update may be failing because a package includes an invalid key. This may be the yarn package, spitting out GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures were invalid: EXPKEYSIG XXXXXXXX Yarn Packaging <yarn@dan.cx>. If you add apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com this may resolve that issue. See https://github.com/yarnpkg/yarn/issues/7866

You may see a codeship error like:
2 errors occurred:
* (step: dependencies_X-deps) error loading services during run step: failure to build Image{ name: "static.X", dockerfile: "/<project-path>/docker/app/Dockerfile", cache: true }: The command '/bin/sh -c apt-get update -y   && wget https://dl.google.com/linux/direct/google-chrome-stable_beta_amd64.deb   && apt-get install -y ./google-chrome-stable_beta_amd64.deb   && rm google-chrome-stable_beta_amd64.deb   && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100
…

With codeship steps, if you edit the Dockerfile RUN command, and it is equivalent to a previous version of that RUN command, that command will be cached and may not trigger an error you expect. In this case it was more painful when trying to add a separate and new RUN command with apt-get install -y libxss1 while updating the build to have a chrome install with the libXss dependency included.

The ubuntu stable package may no longer work for you if you are using puppeteer in conjunction with a headless chrome browser to generate screen captures/pdfs on a server. It can be a bit painful to locate a list of package versions for chrome on ubuntu, and sticking with stable and adding a apt-get install -y libxss1 to your RUN command is one way to go. This may stem from seeing something like:
/app/pdf-thing/node_modules/puppeteer/.local-chromium/linux-XXXXX/chrome-linux/chrome: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory

TCP versus unix socket sock connection refused failure for php5 fpm and nginx

[error] 13169#0: *7 connect() failed (111: Connection refused) while connecting to upstream, client: XXX.XXX.XXX.XXX, server: test.local, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "test.local"

When setting up nginx to work with php-fpm on ubuntu 14.04, this happened when I was using some config templates from a bit older server. It seems to result from nginx being configured to listen with a socket connection versus TCP, and the virtual host being configured to listen with TCP. The fix was somewhat intuitive, but I never would have thought to look in /etc/php5/fpm/pool.d/www.conf.

The fix for me: In /etc/php5/fpm/pool.d/www.conf, change
listen = /var/run/php5-fpm.sock
TO
listen = 127.0.0.1:9000

This should match the php line in your /etc/nginx/sites-enabled/WHATEVERCONFIG. Mine uses TCP with the line
fastcgi_pass 127.0.0.1:9000;
as opposed to
fastcgi_pass unix:/var/run/php5-fpm.sock;

http://stackoverflow.com/questions/15852884/nginx-connect-failed-error