Buenas lista.
Tengo un error 500 al tratar de leer un fichero yml en producción, es
“raro” por que en local el fichero se lee correctamente, tengo algo asi:
config/initializers/users.rb
require ‘yaml’
APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/users.yml")
config/users.yml
username: yo
password: 123456
En producción me lanza el error “uninitialized constant” haciendo
referencia a APP_CONFIG
Creo que es “raro” por que la app al inicializarse si carga
correctamente el fichero yml de la base de datos, con lo cual no es
tema de que falte la libreria yaml en el servidor ¿no?
Gracias por la ayuda que puedan facilitarme.
Un saludo.
On Sat, Sep 20, 2008 at 12:11 AM, alarkspur [email protected] wrote:
Tengo un error 500 al tratar de leer un fichero yml en producción, es “raro”
por que en local el fichero se lee correctamente, tengo algo asi:
config/initializers/users.rb
require ‘yaml’
APP_CONFIG = YAML.load_file(“#{RAILS_ROOT}/config/users.yml”)
config/users.yml
username: yo
password: 123456
En producción me lanza el error “uninitialized constant” haciendo referencia
a APP_CONFIG
O sea, user.rb se ejecuta sin problema y el error salta en otro lugar
al tratar de usar la constante? Si es asi puedes enviar el lugar donde
sucede y la traza de error tal cual con copy & paste?
On Sat, Sep 20, 2008 at 00:11, alarkspur [email protected] wrote:
a APP_CONFIG
Creo que es “raro” por que la app al inicializarse si carga correctamente el
fichero yml de la base de datos, con lo cual no es tema de que falte la
libreria yaml en el servidor ¿no?
Gracias por la ayuda que puedan facilitarme.
Un saludo.
¿Estás utilizando la misma versión de Rails en producción y en
desarrollo? (ya sea “freezeada” o mediante gemas). Porque los
initializers son relativamente modernos (¿Rails 2.1?).
También podrÃas hacer que ese initializer tuviera un efecto que
pudieses observar: escribir en un log, crear un archivo temporal, …
de forma que puedas comprobar que esa lÃnea sà se ejecuta.
Suerte.
¿Estás utilizando la misma versión de Rails en producción y en
desarrollo?
la versión de rails es la 2.1.0 1que tengo congelada en vendor.
O sea, user.rb se ejecuta sin problema y el error salta en otro lugar
al tratar de usar la constante? Si es asi puedes enviar el lugar donde
sucede y la traza de error tal cual con copy & paste?
sucede cuando hace la autentificación en el metodo login de un
controlador, en mi caso en el application, tambien probando <%=
APP_CONFIG.inspect %> he visto que se genera el mismo error si se usa
la constante en las vistas
def login
authenticate_or_request_with_http_basic do |username, password|
if username == APP_CONFIG[‘username’] && password ==
APP_CONFIG[‘password’]
session[:user] = APP_CONFIG[‘username’]
end
end
end
El log
Processing ApplicationController#login (for 84.245.71.217 at
2008-09-20 00:59:26) [GET]
Session ID: 4e115d86af526c18e930d7d98a401d55
Parameters: {“action”=>“login”, “controller”=>“application”}
Completed in 0.00056 (1773 reqs/sec) | Rendering: 0.00035 (62%) | DB:
0.00000 (0%) | 401 Unauthorized [http://miservidordepruebas.com/login]
Processing ApplicationController#login (for 84.245.71.217 at
2008-09-20 00:59:33) [GET]
Session ID:
BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo
SGFzaHsABjoKQHVzZWR7AA==–b7e9df11fb3c65b35e7b7fa5a70d2eba416411dc
Parameters: {“action”=>“login”, “controller”=>“application”}
NameError (uninitialized constant ApplicationController:: APP_CONFIG):
/vendor/rails/activerecord/lib/…/…/activesupport/lib/
active_support/dependencies.rb:492:in const_missing' /app/controllers/application.rb:13:in
login’
/vendor/rails/actionpack/lib/action_controller/
http_authentication.rb:95:in call' /vendor/rails/actionpack/lib/action_controller/ http_authentication.rb:95:in
authenticate’
/vendor/rails/actionpack/lib/action_controller/
http_authentication.rb:85:in authenticate_with_http_basic' /vendor/rails/actionpack/lib/action_controller/ http_authentication.rb:81:in
authenticate_or_request_with_http_basic’
/app/controllers/application.rb:12:in login' /vendor/rails/actionpack/lib/action_controller/base.rb:1162:in
send’
/vendor/rails/actionpack/lib/action_controller/base.rb:1162:in
perform_action_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:580:in
call_filters’
/vendor/rails/actionpack/lib/action_controller/filters.rb:573:in
perform_action_without_benchmark' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 68:in
perform_action_without_rescue’
/usr/local/lib/ruby/1.8/benchmark.rb:293:in measure' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 68:in
perform_action_without_rescue’
/vendor/rails/actionpack/lib/action_controller/rescue.rb:201:in
perform_action_without_caching' /vendor/rails/actionpack/lib/action_controller/caching/ sql_cache.rb:13:in
perform_action’
/vendor/rails/activerecord/lib/active_record/connection_adapters/
abstract/query_cache.rb:33:in cache' /vendor/rails/activerecord/lib/active_record/query_cache.rb:8:in
cache’
/vendor/rails/actionpack/lib/action_controller/caching/
sql_cache.rb:12:in perform_action' /vendor/rails/actionpack/lib/action_controller/base.rb:529:in
send’
/vendor/rails/actionpack/lib/action_controller/base.rb:529:in
process_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:569:in
process_without_session_management_support’
/vendor/rails/actionpack/lib/action_controller/
session_management.rb:130:in sass_old_process' /home/miservidordepruebas/ruby/gems/gems/haml-2.0.2/lib/sass/ plugin/rails.rb:19:in
process’
/vendor/rails/actionpack/lib/action_controller/base.rb:389:in
process' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 149:in
handle_request’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
107:in dispatch' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 104:in
synchronize’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
104:in dispatch' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 120:in
dispatch_cgi’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
35:in dispatch' /vendor/rails/railties/lib/fcgi_handler.rb:103:in
process_request’
/vendor/rails/railties/lib/fcgi_handler.rb:153:in
with_signal_handler' /vendor/rails/railties/lib/fcgi_handler.rb:101:in
process_request’
/vendor/rails/railties/lib/fcgi_handler.rb:78:in
process_each_request' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in
each_cgi’
/usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in
each' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in
each_cgi’
/vendor/rails/railties/lib/fcgi_handler.rb:77:in
process_each_request' /vendor/rails/railties/lib/fcgi_handler.rb:76:in
catch’
/vendor/rails/railties/lib/fcgi_handler.rb:76:in
process_each_request' /vendor/rails/railties/lib/fcgi_handler.rb:50:in
process!’
/vendor/rails/railties/lib/fcgi_handler.rb:24:in `process!’
dispatch.fcgi:24
Rendering /home/miservidordepruebas/app/public/500.html (500 Internal
Server Error)
On Sat, Sep 20, 2008 at 1:10 AM, alarkspur [email protected] wrote:
Es muy raro. Dejame preguntar mas cosas:
-
Si lanzas la consola en produccion y evaluas APP_CONFIG a pelo que
pasa?
-
Si corres en tu maquina la app en modo produccion que pasa?
-
Que sistemas operativos hay en cada caso?
-
Si produccion es un Unix puedes cambiar las credenciales,
reproducir el pete con esas, ejecutar esto
od -t c config/users.yml
en una shell y enviar el ouput? Si puedes usar pastie para evitar
word-wrap mejor.
On Sat, Sep 20, 2008 at 3:13 AM, alarkspur [email protected] wrote:
Muchas gracias por la paciencia y ayuda, ya veras como al final es una
tonterÃa.
Puedes hacer lo mismo con el initializer que lo carga?
Muchas gracias, yo ya no sabia que probar
- Si lanzas la consola en produccion y evaluas APP_CONFIG a pelo
que pasa?
- Si corres en tu maquina la app en modo produccion que pasa?
En el servidor
NameError: uninitialized constant APP_CONFIG
from /home/miservidordepruebas/app/vendor/rails/activerecord/
lib/…/…/activesupport/lib/active_support/dependencies.rb:278:in
load_missing_constant' from /home/miservidordepruebas/app/vendor/rails/activerecord/ lib/../../activesupport/lib/active_support/dependencies.rb:467:in
const_missing’
from /home/miservidordepruebas/app/vendor/rails/activerecord/
lib/…/…/activesupport/lib/active_support/dependencies.rb:479:in
`const_missing’
from (irb):3
pero… esto si lo había probado y es lo que mas “mosca” me tiene,
si en el servidor en la consola en producción ejecuto YAML funciona
correctamente
$ script/console production
APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/users.yml")
=> {“username”=>“yo”, “password”=>123456}
APP_CONFIG
=> {“username”=>“yo”, “password”=>123456}
En local todo OK tanto en development como en production,
APP_CONFIG
=> {“username”=>“yo”, “password”=>“123456”}
- Que sistemas operativos hay en cada caso?
En el servidor en produccion es un Linux Red Hat y mac osx en local
od -t c config/users.yml
en una shell y enviar el ouput?
0000000 u s e r n a m e : y o \n p a s
0000020 s w o r d : 1 2 3 4 5 6 \n
0000036
Muchas gracias por la paciencia y ayuda, ya veras como al final es una
tontería.
Saludos.
config/initializers/app_config.rb
0000000 r e q u i r e ’ y a m l ’ \n A
0000020 P P _ C O N F I G = Y A M L
0000040 . l o a d _ f i l e ( " # { R A
0000060 I L S _ R O O T } / c o n f i g
0000100 / u s e r s . y m l " ) \n
El 20/09/2008, a las 3:19, Xavier N. escribió:
Puedes entrar en la consola de producción y llamar a APP_CONFIG?
Eso te ha de funcionar.
Todo parece correcto asi que vamos a ir poco a poco.
Si una constante fue definida aunque hagas mil cosas con lo que
almacena la constante sigue ahi salvo que ejecutes un remove_const.
La primera conjetura seria que el initializer NO se esta ejecutando en
produccion. Eso seria facil de verificar poniendo una traza.
Si es asi, la siguiente conjetura seria que Rails en realidad no es
2.1 en produccion. No se que cosa rara podria hacer que este en
vendor, una posibilidad loca seria que en desarrollo tengas en
realidad un link simbolico, pero lo veo improbable.
Sea como sea, si podemos determinar algo de eso habremos avanzado.
Desafortunadamente script/about llevaba muchisimo tiempo sin funcionar
en modo produccion:
http://dev.rubyonrails.org/ticket/8349
y no fue hasta hace poco que se arreglo:
#370 script/about not working - Ruby on Rails - rails
Si una constante fue definida aunque hagas mil cosas con lo que
almacena la constante sigue ahi salvo que ejecutes un remove_const.
no, no ejecuto remove_const en ningún momento
La primera conjetura seria que el initializer NO se esta ejecutando en
produccion. Eso seria facil de verificar poniendo una traza.
Aquí me tienes que echar (aun más si cabe) una ayudita, no se como
tirar una traza en producción, imagino que te referiras a escribir en
el log ¿no?
en config/environments/production he añadido
config.log_level = :debug
y luego en el inicializador un
logger.info “=============”
ejecuto nuevamente la app pero no me lo muestran en log/production.log
Al final creo que lo mejor sera cambiar la constante por un string
donde se evalúa y listo 
Saludos
2008/9/20 alarkspur [email protected]:
el log ¿no?
en config/environments/production he añadido
config.log_level = :debug
y luego en el inicializador un
logger.info “=============”
Si. De hecho logger.info sale en production.log sin necesidad de tocar
configuracion.
Parece que el fichero no se ejecuta, vamos a seguir esa pista. Ahora
lanzaria la consola y evaluaria
Rails::VERSION::STRING
Podria ser que tengas algun
config.gem
en environtment.rb que no se cumpla y por algun motivo se esta
enmascarando el pete? Si tienes alguno puedes revisar que todas esas
gemas estan instaladas?
Has hecho en la consola:
APP_CONFIG
2008/9/20 alarkspur [email protected]:
2008/9/20 Xavier N. [email protected]:
Parece claro que no ejecuta el initializer.
Has modificado el boot.rb? Puedes mandar un pastie con su contenido?
Igualmente comentar que a mi no me cuadra. Como estas subiendo los
ficheros al servidor? Que no sea que no tenga un boot incorrecto en el
servidor.
2008/9/20 Xavier N. [email protected]:
Podria ser que tengas algun
config.gem
en environtment.rb que no se cumpla y por algun motivo se esta
enmascarando el pete? Si tienes alguno puedes revisar que todas esas
gemas estan instaladas?
Valga decir que esta pregunta esta motivada por la implementacion de
la carga de initializers:
def load_application_initializers
if @gems_dependencies_loaded
Dir["#{configuration.root_path}/config/initializers/**/*.rb"].sort.each
do |initializer|
load(initializer)
end
end
end
Si no entra en el if no se ejecuta la carga, que es lo que observamos.
Ese flag basicamente dice que todos los config.gem fueron cargados.
On Sat, Sep 20, 2008 at 3:45 PM, Francesc E.
[email protected] wrote:
Has hecho en la consola:
APP_CONFIG
Si esta unos mensajes mas arriba, y copy and paste del codigo del
initializer carga el fichero en consola, por lo que hay que suponer
que el codigo y el nombre del fichero en la maquina de produccion son
correctos.
Parece claro que no ejecuta el initializer.
Interesante … entonces si las gemas necesarias no se han cargado, la
aplicación no deberia arrancar no?
2008/9/20 Xavier N. [email protected]:
2008/9/20 Francesc E. [email protected]:
Interesante … entonces si las gemas necesarias no se han cargado, la
aplicación no deberia arrancar no?
Parece ser que no, sale un warning pero arranca, observa el mensaje
que aparece por ahi sobre la gema foo:
fxn@feynman:~/tmp/test_gem$ script/server
=> Booting Mongrel (use ‘script/server webrick’ to force WEBrick)
=> Rails 2.1.0 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
These gems that this application depends on are missing:
- foo
Run “rake gems:install” to install them.
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no
restart).
** Rails signals registered. HUP => reload (without restart). It
might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000
** Use CTRL-C to stop.
Me parece que es buena pista.