How to address 'OSError: libc not found' raised on Gunicorn exec of Flask app inside Alpine docker container

Question

I'm working on a Flask application based on the Microblog app from Miguel Grinberg's mega-tutorial. Code lives here: https://github.com/dnilasor/quickgig . I have a working docker implementation with a linked MySQL 5.7 container. Today I added an Admin View function using the Flask-Admin module. It works beautifully served locally (OSX) on Flask server via 'flask run' but when I build and run the new docker image (based on python:3.8-alpine), it crashes on boot with a OSError: libc not found error, the code for which seems to indicate an unknown library

It looks to me like Gunicorn is unable to serve the app following my additions. My classmate and I are stumped!

I originally got the error using the python:3.6-alpine base image and so tried with 3.7 and 3.8 to no avail. I also noticed that I was redundantly adding PyMySQL, once in requirements.txt specifying version no. and again explicitly in the dockerfile with no spec. Removed the requirements.txt entry. Also tried incrementing the Flask-Admin version no. up and down. Also tried cleaning up my database migrations as I have seen multiple migration files causing the container to fail to boot (admittedly this was when using SQLite). Now there is only a single migration file and based on the stack trace it seems like the flask db upgrade works just fine.

One thing I have yet to try is a different base image (less minimal?), can try soon and update this. But the issue is so mysterious to me that I thought it time to ask if anyone else has seen it : )

I did find this socket bug which seemed potentially relevant but it was supposed to be fully fixed in python 3.8.

Also FYI I followed some of the advice here on circular imports and imported my admin controller function inside create_app.

Dockerfile:

FROM python:3.8-alpine

RUN adduser -D quickgig

WORKDIR /home/quickgig

COPY requirements.txt requirements.txt
RUN python -m venv venv
RUN venv/bin/pip install -r requirements.txt
RUN venv/bin/pip install gunicorn pymysql

COPY app app
COPY migrations migrations
COPY quickgig.py config.py boot.sh ./
RUN chmod +x boot.sh

ENV FLASK_APP quickgig.py

RUN chown -R quickgig:quickgig ./
USER quickgig

EXPOSE 5000
ENTRYPOINT ["./boot.sh"]

boot.sh:

#!/bin/sh
source venv/bin/activate
while true; do
    flask db upgrade
    if [[ "$?" == "0" ]]; then
        break
    fi
    echo Upgrade command failed, retrying in 5 secs...
    sleep 5
done
# flask translate compile
exec gunicorn -b :5000 --access-logfile - --error-logfile - quickgig:app

Implementation in init.py:

from flask_admin import Admin
app_admin = Admin(name='Dashboard')

def create_app(config_class=Config):
  app = Flask(__name__)
  app.config.from_object(config_class)
...
  app_admin.init_app(app)

...
  from app.admin import add_admin_views
  add_admin_views()
...
  return app

from app import models

admin.py:

from flask_admin.contrib.sqla import ModelView
from app.models import User, Gig, Neighborhood
from app import db
# Add views to app_admin

def add_admin_views():
    from . import app_admin
    app_admin.add_view(ModelView(User, db.session))
    app_admin.add_view(ModelView(Neighborhood, db.session))
    app_admin.add_view(ModelView(Gig, db.session))

requirements.txt:

alembic==0.9.6
Babel==2.5.1
blinker==1.4
certifi==2017.7.27.1
chardet==3.0.4
click==6.7
dominate==2.3.1
elasticsearch==6.1.1
Flask==1.0.2
Flask-Admin==1.5.4
Flask-Babel==0.11.2
Flask-Bootstrap==3.3.7.1
Flask-Login==0.4.0
Flask-Mail==0.9.1
Flask-Migrate==2.1.1
Flask-Moment==0.5.2
Flask-SQLAlchemy==2.3.2
Flask-WTF==0.14.2
guess-language-spirit==0.5.3
idna==2.6
itsdangerous==0.24
Jinja2==2.10
Mako==1.0.7
MarkupSafe==1.0
PyJWT==1.5.3
python-dateutil==2.6.1
python-dotenv==0.7.1
python-editor==1.0.3
pytz==2017.2
requests==2.18.4
six==1.11.0
SQLAlchemy==1.1.14
urllib3==1.22
visitor==0.1.3
Werkzeug==0.14.1
WTForms==2.1

When I run the container in interactive terminal I see the following stack trace:

(venv) ****s-MacBook-Pro:quickgig ****$ docker run -ti quickgig:v7
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> 1f5feeca29ac, test
Traceback (most recent call last):
  File "/home/quickgig/venv/bin/gunicorn", line 6, in <module>
    from gunicorn.app.wsgiapp import run
  File "/home/quickgig/venv/lib/python3.8/site-packages/gunicorn/app/wsgiapp.py", line 9, in <module>
    from gunicorn.app.base import Application
  File "/home/quickgig/venv/lib/python3.8/site-packages/gunicorn/app/base.py", line 12, in <module>
    from gunicorn.arbiter import Arbiter
  File "/home/quickgig/venv/lib/python3.8/site-packages/gunicorn/arbiter.py", line 16, in <module>
    from gunicorn import sock, systemd, util
  File "/home/quickgig/venv/lib/python3.8/site-packages/gunicorn/sock.py", line 14, in <module>
    from gunicorn.socketfromfd import fromfd
  File "/home/quickgig/venv/lib/python3.8/site-packages/gunicorn/socketfromfd.py", line 26, in <module>
    raise OSError('libc not found')
OSError: libc not found

I'd like the app to boot/be served by gunicorn inside the container so I can continue developing with my team using the docker implementation and leveraging dockerized MySQL vs the pain of local MySQL for development. Can you advise?

Answer 1

In your Dockerfile:

RUN apk add binutils libc-dev

Answer 2

Yes Gunicorn 20.0.0 requires the package libc-dev.

So this works for me:

RUN apk --no-cache add libc-dev

Answer 3

This problem seems related to a new version of Gunicorn 20.0.0. Try to use a previous one 19.9.0

Answer 4

This was an issue with gunicorn 20.0.0, tracked here: https://github.com/benoitc/gunicorn/issues/2160

The issue is fixed in 20.0.1 and forward. So, change this:

RUN venv/bin/pip install gunicorn pymysql

to this:

RUN venv/bin/pip install 'gunicorn>=20.0.1,<21' pymysql

---

If upgrading is not an option, as a workaround you can add the following line:

RUN apk --no-cache add binutils musl-dev

Unfortunately this adds about 20MB to the resulting docker container, but there isn't any other known workaround at the moment.