Puma silently exits inside docker container

[Deekor]

Rails 5.2.3
Puma 3.12.1

Ive dockerized my rails app and when I start the container with the command rails s puma, Puma boots and then silently exits:

=> Booting Puma
=> Rails 5.2.3 application starting in production 
=> Run `rails server -h` for more startup options

There are no more logs after that and the container is no longer running. Puma still works fine outside of docker.

Any ideas?

[nateberkopec]

Can I get a Dockerfile that reproduces the issue?

[Deekor]

Dockerfile

FROM ruby:2.4.5
RUN sed -i '/jessie-updates/d' /etc/apt/sources.list

RUN curl -sL https://deb.nodesource.com/setup_10.x | bash - && \
    apt-get update -qq && apt-get install -y build-essential nodejs && \
    apt-get clean

RUN gem install bundler  # ensure bundler 2
RUN gem cleanup

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \
    echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && \
    apt-get update && apt-get install -y apt-utils yarn && \
    gem install rails -v 5.2.3

ARG environment
RUN echo $environment
ENV RAILS_ENV=$environment
ENV DOCKER_IMAGE_BUILD=true

# ------------------------
# SSH Server support
# ------------------------
RUN apt-get update \
    && apt-get install -y --no-install-recommends openssh-server build-essential nodejs cron nano systemd \
    && echo "root:Docker!" | chpasswd

COPY sshd_config /etc/ssh/
	
RUN mkdir /myapp
WORKDIR /myapp
COPY . /myapp

RUN bundle -v

RUN bundle install
RUN yarn install


EXPOSE 3000 2222

COPY init_container.sh /myapp
RUN chmod 755 /myapp/init_container.sh

ENTRYPOINT ["/myapp/init_container.sh"]

init_container.sh:

#!/usr/bin/env bash
cat >/etc/motd <<EOL
  _____
  /  _  \ __________ _________   ____
/  /_\  \\___   /  |  \_  __ \_/ __ \
/    |    \/    /|  |  /|  | \/\  ___/
\____|__  /_____ \____/ |__|    \___  >
        \/      \/                  \/
A P P   S E R V I C E   O N   L I N U X

Documentation: http://aka.ms/webapp-linux
NodeJS quickstart: https://aka.ms/node-qs

EOL
cat /etc/motd

service ssh start

# whenever has to be run from the main app folder.
# it will look for schedule.rb in /myapp/config folder
cd /myapp
whenever --update-crontab
# restart cron after updating crontab
service cron restart
# for logging
crontab -l

bundle exec rails assets:precompile
yarn install

rails s puma

[dannyfallon]

I've tried to repro this without success using Rails 5.2.3 and Ruby 2.4.5. This might be a bit easier if you pushed your container somewhere like Docker Hub and shared it or pointed out what I'm doing wrong?

I generated a brand new Rails app called myapp and it's working just fine. A few things I ran into trying to get this to work:

1. There's no sshd_config supplied, so I skipped that line.
2. There's no config/schedule.rb supplied for whenever, which produces a non-fatal error.

Here is my output:

➜  myapp git:(master) ✗ docker run myapp
  _____
  /  _  \ __________ _________   ____
/  /_\  \___   /  |  \_  __ \_/ __ /    |    \/    /|  |  /|  | \/\  ___/
\____|__  /_____ \____/ |__|    \___  >
        \/      \/                  \/
A P P   S E R V I C E   O N   L I N U X

Documentation: http://aka.ms/webapp-linux
NodeJS quickstart: https://aka.ms/node-qs

Starting OpenBSD Secure Shell server: sshd.
[fail] Can't find file: config/schedule.rb
Restarting periodic command scheduler: cronStopping periodic command scheduler: cron.
Starting periodic command scheduler: cron.
no crontab for root
yarn install v1.15.2
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.10s.
I, [2019-05-04T23:06:18.968142 #43]  INFO -- : Writing /myapp/public/assets/application-9dcb1626850e8ac8a42c5643d632ef67f743043da887857b887306ce35674069.js
I, [2019-05-04T23:06:18.969018 #43]  INFO -- : Writing /myapp/public/assets/application-9dcb1626850e8ac8a42c5643d632ef67f743043da887857b887306ce35674069.js.gz
I, [2019-05-04T23:06:18.974848 #43]  INFO -- : Writing /myapp/public/assets/application-f0d704deea029cf000697e2c0181ec173a1b474645466ed843eb5ee7bb215794.css
I, [2019-05-04T23:06:18.975139 #43]  INFO -- : Writing /myapp/public/assets/application-f0d704deea029cf000697e2c0181ec173a1b474645466ed843eb5ee7bb215794.css.gz
yarn install v1.15.2
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.10s.
=> Booting Puma
=> Rails 5.2.3 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.12.1 (ruby 2.4.5-p335), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment:
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
Started GET "/" for 127.0.0.1 at 2019-05-04 23:07:00 +0000
Processing by Rails::WelcomeController#index as */*
  Rendering /usr/local/bundle/gems/railties-5.2.3/lib/rails/templates/rails/welcome/index.html.erb
  Rendered /usr/local/bundle/gems/railties-5.2.3/lib/rails/templates/rails/welcome/index.html.erb (3.6ms)
Completed 200 OK in 31ms (Views: 11.5ms | ActiveRecord: 0.0ms)

[Marri]

I'm recently having issues getting my Rails app to boot in my Dockerfile. The problem appears between these commits: glowfic-constellation/glowfic@57c913b...f14fae9; I can check out the first commit and have the app work perfectly, I check out the second and it reliably fails. I suspect this may be related and am posting here for others in case it constitutes a repro; off to try things myself like "don't upgrade Puma patch versions" or "move puma around in my Gemfile".

Edit/update: moving the puma gem out of the production group had no effect; downgrading puma 3.12.1 to 3.12.0 fixed the problem.

[dentarg]

@Marri are you able to try out the Puma master branch? it might have been fixed as bunch of stuff hasn't been released yet

here's the diff between 3.12.0 and 3.12.1 if anyone wants to take a look: v3.12.0...v3.12.1

[Marri]

@dentarg sure! But no luck :/ Things done for debugging posterity:

• Had the Docker container running on 3.12.0. Updated the gemfile to 3.12.1, ran bundle install, refreshed; nothing went wrong. (This is kinda a dumb case since I'm sure it takes a restart to kick in, but hey, documentation.)
• Spun down the container, rebuilt it, spun it up. As expected, nothing will load.
• Switched the puma gem in my file to point to:
  gem 'puma', :git => 'https://github.com/puma/puma.git', :branch => 'master', ran down/build/up and still nothing works
• reverted change to Gemfile so we're back to 3.12.0, down/build/up and for some reason it built from cache and it still didn't work
• down/build without cache/up and it works again on 3.12.0

[tarellel]

@Deekor and @Marri
I've been running puma in a number of docker containers for months with no issue. They also have a number of cronjobs associated with them. Can you do us a favor and build your applications container such as docker build -t my_rails_app:0.0.1. Or at least something similar and rather than doing a docker run -it my_rails_app:0.0.1 to run the container try running the container as a bash session within the container and than run rails s. You can achieve this by running docker run -p 3000:3000 -it my_rails_app:0.0.1 bash now that your running inside the container cd to the applications directory and run rails s. This will be similar to as if you are running rails s locally, but within the container and see if the rails applications runs. If this doesn't work, you know there's more than likely issues with your application or the docker build.

---

@Deekor
The other issue I'm seeing with your deployment is it looks like you're trying initialize a number of long standing processing within init_container.sh. One is the whenever task, which is a ruby test for building cronjobs, you're starting up the ssh service, and the other task is rails s.

I've got a number of cron jobs running with one of my applications. To do this I build the container and run a difference long standing process as a service in a docker-compose.yml or docker-stack.yml deployment. As you can see in the dockerfile I install and setup cron. The who cron.allow thing is because I run my app as the USER app rather than root. I than create the cronjob in the container, but I don't run it. In the docker compose file I have 1 service for running the application container. But I than have another service to run the cronjob to run a rake task or whatever Ruby/Rails script that may be required. But seeing as how you're using the whenever gem you may have to call whenever --update-crontab instead of cron -f

# Dockerfile
# Install crontab and give the user 'app' access to be call and run cronjobs
RUN addgroup crontab && \
    apt-get -qq update && apt-get install -y cron && \
    apt-get clean && rm -rf /var/lib/apt/lists/* && \
    touch /var/log/cron.log && touch /etc/cron.allow && \
    echo "app" > /etc/cron.allow

# Create a cronjob to run a specific task
RUN (crontab -l ; echo "*/5 * * * * cd /app && RAILS_ENV=production /usr/local/bundle/bin/bundle exec rake sometask > /dev/null") | crontab

# docker-compose.yml
version: 3.7

# Config that need to be passed to both the application and service containers
x-common-defaults: &app-defaults
  image: my_rails_app:0.0.1
  environment:
    - RAILS_ENV=${RAILS_ENV}
    - RAILS_MASTER_KEY=${RAILS_MASTER_KEY}
  
services:
  app:
    <<: *app-defaults
    command: rails s
    volumes:
      - public:/volumes/public
  cron:
    <<: *app-defaults
    command: cron -f
volumes:
  public:

~ Note this is just snip and should be modified to suite your applications needs.

[Marri]

Sorry I missed this @tarellel; editing a comment with an @ must not ping me :/ Just came back to this because we're trying to do another round of gem upgrades and took the steps mentioned; turned off the web container (docker-compose down), ran bash on my web container (docker-compose run --rm web bash), started rails s, and got the exact same thing I see in my logs which is:

=> Booting Puma
=> Rails 5.2.3 application starting in development 
=> Run `rails server -h` for more startup options
[14] Puma starting in cluster mode...
[14] * Version 4.0.1 (ruby 2.6.3-p62), codename: 4 Fast 4 Furious
[14] * Min threads: 5, max threads: 5
[14] * Environment: development
[14] * Process workers: 2
[14] * Preloading application
[14] * Listening on tcp://localhost:3000
[14] Use Ctrl-C to stop
[14] - Worker 0 (pid: 22) booted, phase: 0
[14] - Worker 1 (pid: 34) booted, phase: 0

Despite what the logs claim, it does not work and the app refuses to load. When I spin down web, it even prints

web_1       | [1] - Gracefully shutting down workers...
web_1       | [1]     worker status: pid 13 exit 0
web_1       | [1]     worker status: pid 25 exit 0
web_1       | [1]     worker shutdown time:   0.50
web_1       | Exiting

and yet, localhost:3000 has... nothing. Problem still exists.

Feel free to try yourself: https://github.com/Marri/glowfic

[Marri]

Update: PROGRESS.
Puma 3.12.0 listens on tcp://0.0.0.0:3000
Puma 4.0.1 appears to listen on tcp://localhost:3000
Puma 4.2.0 appears to listen on tcp://127.0.01:3000
Time to figure out what it's doing and make it work.

Update the second:
Yeah okay my problem was caused by #1700, I restored the original behavior and we're back now.