Werkzeug: 0.15.0 verursacht OSError: [Errno 8] Exec-Formatfehler: in Docker für Windows

Hallo gleiches Problem hier. Getestet auf

• Centos 7.4 mit Python 3.6
• Mac OSX 10.14.3 mit Python 3.7

Dies wird durch die Änderungen in _get_args_for_reloading() in _reloading.py verursacht.

Gegeben ist der obige Code in einer Datei namens app.py, wobei cwd() /home/user/Projects/test/ ist

_get_args_for_reloading() ergibt Folgendes:

Mit 0.14.1 :

['/home/user/.virtualenvs/test-ChRUEUMK/bin/python', 'app.py']

Mit 0.15.0

['/home/user/Projects/test/app.py']

Das Voranstellen /home/user/.virtualenvs/test-ChRUEUMK/bin/python an den Pfad behebt das Problem.

@shinuza prüfen, ob app.py ausführbar ist, wenn ja - chmod 644 app.py setzen. Oder zweitens, fügen Sie Shebang oben auf app.py hinzu, wie #!/usr/bin/env python

@shinuza dort https://github.com/pallets/werkzeug/blob/0.15.x/src/werkzeug/_reloader.py#L90 Zeilen 90-94 die „/home/user/.virtualenvs/test-ChRUEUMK/bin /python'" wurde entfernt, wenn app.py ausführbar ist.
und OSError: [Errno 8] Exec-Formatfehler: '/usr/src/app/app.py passierte, weil app.py keine Shebang-Zeile hat (https://stackoverflow.com/questions/27606653/oserror-errno- 8-Exec-Format-Fehler)

@kamyanskiy Ich habe das gerade beim Lesen des Codes herausgefunden, aber der Fehler sollte so kryptisch sein wie jetzt.

Wenn ich explizit python app.py ausführe, sollte der Unterprozess keine Annahmen treffen und die Art und Weise ändern, wie ich die Anwendung ausführe. dh: Das Arbeiten mit einer virtuellen Maschine mit freigegebenem Ordner macht alle Dateien standardmäßig ausführbar.

@shinuza Ich denke nicht, dass es ein kritischer Fehler ist, mit anderen Worten, es ist jetzt etwas strenger als zuvor. Also sollte ich keine ausführbare app.py ohne Shebang haben, es macht keinen Sinn. Und zweitens sollte ich keine ausführbare Datei mit Shebang wie "python app.py" ausführen. Aber ich stimme zu, wahrscheinlich war das für Sie wie für mich unerwartet :) Um dies zu umgehen, fügen Sie einfach Shebang zu Ihrer app.py hinzu, ich hoffe, das wird helfen.

Wenn Sie ein Skript als ausführbar markieren, sollten Sie oben einen entsprechenden Interpreter-Kommentar hinzufügen. Sie können ein Tool wie den Hook check-executables-have-shebangs pre-commit verwenden, um dies zu erzwingen.

Wenn Sie nicht beabsichtigen, dass ein Skript direkt ausführbar ist, und stattdessen python script.py benötigen, sollten Sie es nicht als ausführbar markieren.

Wie gesagt, ich stimme hier der Hauptlogik zu. Ich bin nicht einverstanden mit der Art und Weise, wie mit dem Fehler umgegangen wird, sowie mit der Tatsache, dass die Fehlermeldung unverständlich ist, es sei denn, Sie kennen die technischen Details oder lesen den Code. Es sollte zumindest im Changelog dokumentiert sein.

Wir haben keinen Einfluss auf die Fehlermeldung, die von Linux kommt. Die Tatsache, dass wir den Umgang mit ausführbaren Dateien geändert haben, ist im Änderungsprotokoll aufgeführt:

Der Reloader stellt die ausführbare Python-Datei nicht der Befehlszeile voran, wenn die Python-Datei als ausführbar markiert ist. Dadurch kann der Reloader unter NixOS arbeiten. #1242

Die Datei nicht ausführbar machen funktioniert. Die Shebang-Linie tut es für mich nicht. Stattdessen erhalte ich Datei nicht gefunden-Fehler. Das war das erste, was ich versuchte.

Mit #!/usr/bin/env python3 :

λ docker run flask_test
 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
 * Restarting with stat
: No such file or directory

Ich denke auch, dass eine Änderung, die nur auf einer Linux-Distribution funktioniert, aber den Rest kaputt macht, nicht ideal erscheint. Die Dateien nicht ausführbar zu machen, scheint die richtige Lösung zu sein, aber das fühlt sich für mich immer noch kaputt an.

@penner42 versuchen Sie #!/usr/bin/env python

root<strong i="7">@4541ebd677e0</strong>:/usr/src/app# ls -la /usr/local/bin/python3
lrwxrwxrwx 1 root staff 9 Mar  4 23:40 /usr/local/bin/python3 -> python3.6
root<strong i="8">@4541ebd677e0</strong>:/usr/src/app# ls -la /usr/local/bin/python 
lrwxrwxrwx 1 root staff 7 Mar  4 23:40 /usr/local/bin/python -> python3

Wahrscheinlich haben Sie keinen Symlink auf Python3

Gleiches Ergebnis. Der python3-Symlink ist da, und es funktioniert einfach, /usr/bin/env python3 oder /usr/bin/env python von einer Shell aus auszuführen.

FWIW, Docker gibt diese Warnung beim Erstellen aus.
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

Verwenden Sie den Befehl flask run .

FROM python:3.7-alpine
WORKDIR /app
ENV FLASK_ENV development
ENV FLASK_APP example
EXPOSE 5000
RUN ["pip", "install", "flask"]
CMD ["flask", "run", "-h", "0.0.0.0"]

docker run --rm -p 5000:5000 -v $(pwd):/app flask/example:latest

Hat das Tutorial unter https://docs.docker.com/compose/gettingstarted/ unter Windows 7 funktioniert?
Ist diese kürzliche Änderung die Ursache, warum ich beim Versuch, das Beispiel auszuführen, einen ähnlichen Fehler sehe:

$ docker-compose up
Creating composetest_web_1   ... done
Creating composetest_redis_1 ... done
Attaching to composetest_web_1, composetest_redis_1
redis_1  | 1:C 27 Mar 2019 17:29:12.746 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1  | 1:C 27 Mar 2019 17:29:12.746 # Redis version=5.0.4, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1  | 1:C 27 Mar 2019 17:29:12.747 # Warning: no config file specified, using the default config. In order to specify a config file use redis-ser
ver /path/to/redis.conf
redis_1  | 1:M 27 Mar 2019 17:29:12.757 * Running mode=standalone, port=6379.
redis_1  | 1:M 27 Mar 2019 17:29:12.757 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to th
e lower value of 128.
redis_1  | 1:M 27 Mar 2019 17:29:12.758 # Server initialized
redis_1  | 1:M 27 Mar 2019 17:29:12.758 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issu
e add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
web_1    |  * Serving Flask app "app" (lazy loading)
web_1    |  * Environment: production
web_1    |    WARNING: Do not use the development server in a production environment.
web_1    |    Use a production WSGI server instead.
web_1    |  * Debug mode: on
web_1    |  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
web_1    |  * Restarting with stat
web_1    | Traceback (most recent call last):
web_1    |   File "app.py", line 32, in <module>
web_1    |     app.run(host="0.0.0.0", debug=True)
web_1    |   File "/usr/local/lib/python3.4/site-packages/flask/app.py", line 943, in run
web_1    |     run_simple(host, port, self, **options)
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/serving.py", line 988, in run_simple
web_1    |     run_with_reloader(inner, extra_files, reloader_interval, reloader_type)
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/_reloader.py", line 332, in run_with_reloader
web_1    |     sys.exit(reloader.restart_with_reloader())
web_1    |   File "/usr/local/lib/python3.4/site-packages/werkzeug/_reloader.py", line 176, in restart_with_reloader
web_1    |     exit_code = subprocess.call(args, env=new_environ, close_fds=False)
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 534, in call
web_1    |     with Popen(*popenargs, **kwargs) as p:
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 856, in __init__
web_1    |     restore_signals, start_new_session)
web_1    |   File "/usr/local/lib/python3.4/subprocess.py", line 1464, in _execute_child
web_1    |     raise child_exception_type(errno_num, err_msg)
web_1    | OSError: [Errno 8] Exec format error
composetest_web_1 exited with code 1

Habe das gleiche Tutorial gemacht und das gleiche Problem festgestellt. Dies hat es für mich behoben.

Ich habe den folgenden Kram am Anfang meines app.py -Skripts hinzugefügt

#!/usr/local/bin/python3

Was dann zu Berechtigungsproblemen führte. Ich habe dann Folgendes zu meinem Dockerfile vor dem CMD hinzugefügt

RUN chmod 644 app.py

Bitte jeder kann das Tutorial aktualisieren (https://docs.docker.com/compose/gettingstarted/)
hinzufügen

RUN chmod 644 app.py

Änderungen am Docker Compose-Tutorial, vorgeschlagen in https://github.com/docker/docker.github.io/pull/8609.

Fixed in Werkzeug 0.15.5.