Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

356
Vistas
¿Es posible ejecutar el matraz en un solo proceso? (para evitar un problema aparente con ipdb y Docker ttys)

Tengo una aplicación de matraz que estoy ejecutando así:

flask run --host=0.0.0.0

Cuando miro la lista de procesos veo esto:

 UID PID PPID C STIME TTY TIME CMD root 1 0 0 23:48 pts/0 00:00:00 /bin/sh -c flask run --host=0.0.0.0 root 6 1 1 23:48 pts/0 00:00:01 /usr/local/bin/python /usr/local/bin/flask run --host=0.0.0.0 root 8 6 3 23:48 pts/0 00:00:02 /usr/local/bin/python /usr/local/bin/flask run --host=0.0.0.0

Tres procesos.

Si ejecuto usando --without-threads , también hago los mismos tres procesos:

 UID PID PPID C STIME TTY TIME CMD root 1 0 0 00:28 pts/0 00:00:00 /bin/sh -c flask run --host=0.0.0.0 --without-threads root 6 1 2 00:28 pts/0 00:00:02 /usr/local/bin/python /usr/local/bin/flask run --host=0.0.0.0 --without-threads root 8 6 4 00:28 pts/0 00:00:04 /usr/local/bin/python /usr/local/bin/flask run --host=0.0.0.0 --without-threads

¿Hay alguna manera de ejecutar de alguna manera el matraz como un proceso único?

Motivación

La aplicación del matraz en cuestión se ejecuta dentro de un contenedor acoplable. Me gustaría poder establecer puntos de interrupción usando ipdb .

He observado que si configuro esto en mi archivo docker-compose:

 stdin_open: true tty: true

y ejecute, en lugar de una aplicación de matraz, una aplicación python simple de un solo proceso...

 $ docker exec -it bug_demo_bug_demo_1 bash root@98245482089b:/opt/bug_demo/bug_demo# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 00:41 pts/0 00:00:00 /bin/sh -c python app.py root 7 1 20 00:41 pts/0 00:00:00 python app.py

... y adjuntarlo al contenedor mientras la aplicación está en un punto de interrupción, puedo ingresar a ibpd y usarlo normalmente: las teclas de flecha y la finalización de pestañas funcionan correctamente.

Pero cuando trato de hacer lo mismo con la aplicación del matraz (adjuntar al contenedor mientras la aplicación está esperando en un punto de interrupción), las cosas no funcionan correctamente.

O deshabilito tty: true en docker-compose.yml , y puedo usar ipdb pero sin teclas de flecha ni finalización de tabulación, O dejo tty: true en su lugar, pero luego no puedo usar ipdb en absoluto, porque parece que el tty está adjunto a los tres procesos de matraz, lo que hace que todo lo que no sea los comandos de un solo carácter se confunda. (Aunque puedo ver con esta configuración que las teclas de flecha y la finalización de pestañas funcionan).

Todo esto me lleva a creer que si puedo encontrar una manera de ejecutar mi aplicación de matraz como un solo proceso, podré conectarme al contenedor acoplable y usar ipdb como desee.

Hay alguna manera de hacer esto?

Actualización: el problema se manifiesta durante el inicio, no durante el manejo de solicitudes

Tras un examen más detallado, veo que este problema solo se manifiesta durante el código de "inicio". ej: si el punto de interrupción está dentro de la función create_app .

Si el punto de interrupción está dentro de un método de controlador de solicitudes, o código llamado desde un controlador de solicitudes, todo funciona como se esperaba.

El uso de exec reduce el recuento de procesos de tres a dos (el proceso raíz se reemplaza por el primer trabajador), pero el problema aún se manifiesta en los puntos de interrupción dentro de create_app .

Ejecutar el matraz con --no-reload hace que el segundo trabajador desaparezca, por lo que el recuento de procesos puede forzarse a uno o dos, al no usar o usar exec . Ejecutar con --no-reload no es ideal para mi caso de uso, pero hace que el problema desaparezca, incluso para los puntos de interrupción en create_app .

Para mis propósitos, puedo vivir con la limitación de que ipdb solo funciona bien con el terminal dentro de los controladores de solicitudes; no espero una gran necesidad de ejecutar el depurador desde el código de inicio. (Pero aún así aceptaré una respuesta y felizmente otorgaré la recompensa, si alguien puede explicar exactamente qué está sucediendo en el caso del punto de interrupción del código de inicio y por qué el problema no se manifiesta en el caso del punto de interrupción del controlador de solicitudes).

Basado en el hallazgo --no-reload , parece que la descamación subyacente está relacionada de alguna manera con el TTY "compartido" por el proceso de manejo de solicitudes y el proceso de recarga de código.

Información de la versión de Flask y Docker

 ipdb> flask.__version__ '1.0.3'
 $ docker version Client: Docker Engine - Community Version: 18.09.2 API version: 1.39 Go version: go1.10.8 Git commit: 6247962 Built: Sun Feb 10 04:12:39 2019 OS/Arch: darwin/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 18.09.2 API version: 1.39 (minimum version 1.12) Go version: go1.10.6 Git commit: 6247962 Built: Sun Feb 10 04:13:06 2019 OS/Arch: linux/amd64 Experimental: false
 $ docker info Containers: 22 Running: 3 Paused: 0 Stopped: 19 Images: 362 Server Version: 18.09.2 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec init version: fec3683 Security Options: seccomp Profile: default Kernel Version: 4.9.125-linuxkit Operating System: Docker for Mac OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 3.855GiB Name: linuxkit-025000000001 ID: ZAK2:V2VU:IZFF:6MQQ:IFJB:2ZKY:VHA5:CSO3:VXQQ:UK6C:O3I7:S3ZU Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): true File Descriptors: 59 Goroutines: 89 System Time: 2019-07-28T14:00:38.3184372Z EventsListeners: 2 HTTP Proxy: gateway.docker.internal:3128 HTTPS Proxy: gateway.docker.internal:3129 Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine
 $ docker-compose --version docker-compose version 1.23.2, build 1110ad01
over 4 years ago · Santiago Trujillo
3 Respuestas
Responde la pregunta

0

El uso de la aplicación del matraz funciona en un solo proceso síncrono.

Eso solo puede manejar una solicitud a la vez.

Si desea tratar con solicitudes paralelas, debe esperar hasta que se puedan manejar, luego use esto:

 app.run(host=HOST, port=PORT, threaded=True)
over 4 years ago · Santiago Trujillo Denunciar

0

Para hacer que el matraz se ejecute en un solo procesador, use lo siguiente

 if __name__ == '__main__': app.run(threaded=False, processes=1)
over 4 years ago · Santiago Trujillo Denunciar

0

¿Probó los argumentos "--no-debugger"?
Si tiene la variable de entorno DEBUG, cree un proceso de depuración.

 flask run --host=0.0.0.0 --without-threads --no-debugger
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda