2012-01-03 6 views
51

Cuando corro capataz me sale el siguiente:capataz sólo muestra la línea con “comenzó el ingenio pid #” y nada más

> foreman start 
16:47:56 web.1  | started with pid 27122 

Sólo si dejo que (a través de Ctrl-C) que me muestra lo que falta :

^CSIGINT received 
16:49:26 system | sending SIGTERM to all processes 
16:49:26 web.1  | => Booting Thin 
16:49:26 web.1  | => Rails 3.0.0 application starting in development on http://0.0.0.0:5000 
16:49:26 web.1  | => Call with -d to detach 
16:49:26 web.1  | => Ctrl-C to shutdown server 
16:49:26 web.1  | >> Thin web server (v1.3.1 codename Triple Espresso) 
16:49:26 web.1  | >> Maximum connections set to 1024 
16:49:26 web.1  | >> Listening on 0.0.0.0:5000, CTRL+C to stop 
16:49:26 web.1  | >> Stopping ... 
16:49:26 web.1  | Exiting 
16:49:26 web.1  | >> Stopping ... 

¿Cómo puedo repararlo?

+0

Si ha iniciado múltiples tareas que requieren el conjunto de rieles apilar, podría llevar un tiempo lanzar todo. La salida del capataz es instantánea, pero tus trabajos en segundo plano no serán más rápidos de lo habitual. En mi caso, tuve que esperar unos 2 minutos. Entonces ... espéralo. –

Respuesta

47

he sido capaz de resolver este problema por 2 formas diferentes:

  1. De https://github.com/ddollar/foreman/wiki/Missing-Output:

    Si usted no está viendo ningún resultado de su programa, hay una probabilidad posibilidad de que sea buffering stdout. Ruby buffers stdout por defecto. Para desactivar este comportamiento, agregue el código tan pronto como sea posible en su programa :

    # ruby 
    $stdout.sync = true 
    
  2. Mediante la instalación de capataz a través de la heroku toolbelt package

Pero todavía no sé lo que está pasando ni por qué este 2 maneras anteriormente han resuelto el problema ...

+0

¡Esto es súper útil! – Cyrus

+5

+1 - ¡Muchas gracias! Per @Earle Clubb a continuación, agregué la línea '$ stdout.sync = true' a mi archivo' config/environments/development.rb' ¡y funciona perfectamente! –

+2

Ahora solo funciona el 1. Puede ser el segundo usado para trabajar cuando Heroku Toolbelt tenga una versión anterior del capataz. – Saneef

4

que tienen el mismo problema (rubí 1.9.3-p0, carriles 3.2rc2, OSX 10.7).

resuelto el problema mediante el uso de capataz-0.27.0 añadiendo esta línea en mi Gemfile.

gem 'foreman', '0.27.0' 
+0

El mío funcionó cuando instalé el "capataz más general" del paquete heroku toolbelt. El de las gemas no ... – ijverig

4

También tuve el mismo problema pero con una solución diferente. (Rubí 1.9.2p290, los carriles 3.1.0, Ubuntu 10.04.3)

me cambió la línea en mi Procfile de:

web: bundle exec thin start -p $PORT 

a:

web: bundle exec rails server thin -p $PORT 

y ya no dio yo un problema

+0

No. No funcionó. Me muestra un mensaje INFO en webrick, pero solo muestra el arranque mensaje después de un ctrl-c ... – ijverig

+0

Esto funciona para mí (OSX 10.8, capataz 0.60.2), gracias. – grilix

+0

No funciona para mí también. Obteniendo el mismo error. –

14

"Capataz mostrará nada a la salida del terminal por escrito a la salida estándar de los procesos se pone en marcha." - ddollar Ver foreman-issues#57

Por cierto, puede utilizar tailf en Procfile para ver los registros de

web: bundle exec rails server thin -p $PORT 
log: tail -f log/development.log 

Consejo: tailf no existe en OSX, utilizando tail -f -n 40 de registro de obras/development.log.

+1

Esto sirve para el mismo propósito pero no lo hace cambie que los rieles todavía no están descargando sus búfers por alguna razón. Cuando ejecuto 'rails console' y ejecuto STDOUT.sync, se devuelve verdadero, por lo que debería estar sonrojando, pero el capataz todavía no está escribiendo nada del trabajador. – jrbalsano

+2

Rails ** only ** flushes escribe en el archivo de registro cuando finaliza la siguiente solicitud de rack, es manejado por el middleware Rails :: Rack :: Logger. ¿Con qué trabajador hablas? Resque redis? – julionc

+0

Lo siento, por trabajador me refería al tail -f que se está ejecutando. No estoy seguro de por qué, pero definitivamente tengo un entorno de desarrollo donde la web estaba escribiendo todos los mensajes que estoy viendo actualmente por log. – jrbalsano

20

Mi solución fue poner $stdout.sync = true en la parte superior de config/ambientes/desa lopment.rb.

Entonces todo lo que carga el entorno de desarrollo (incluing fina) no amortiguar la salida estándar.

4

Si está utilizando Foreman para ejecutar un proyecto de Python, en lugar de un proyecto de Ryby, y está teniendo el mismo problema, aquí hay algunas soluciones para usted. Si está utilizando un Procfile para invocar la pitón CLI directamente, a continuación, puede utilizar la opción '-u' para evitar la salida estándar de amortiguación:

python -u script.py 

si está utilizando un Procfile para administrar un servidor WSGI, como invocando gunicorn, frasco, botella, víspera, etc, entonces usted puede agregar un archivo ".env" a la raíz de su proyecto pitón, que contiene los siguientes:

PYTHONUNBUFFERED=True 
Cuestiones relacionadas