Avoir du mal à déboguer l'application Sinatra en production

Question

Je déploie une application Sinatra à l'aide de passager. L'application déployée fonctionne, mais pas entièrement: certains chemins fonctionnent correctement, d'autres ne font que restituer une page vierge. Il semble que je ne trouve pas de différences majeures entre les itinéraires qui fonctionnent et ceux qui ne fonctionnent pas, et je ne semble pas pouvoir retrouver aucune erreur.

Gestionnaires

J'ai défini les gestionnaires not_found et error comme suit:

not_found do
  '404. Bummer!'
end

error do
  'Nasty error: ' + env['sinatra.error'].name
end

Cela fonctionne bien sur ma machine locale, tant en développement qu'en production, mais je ne les vois jamais arriver sur le serveur.

Journaux Apache

Lorsque je trace le fichier access.log d'Apache et que je clique sur l'un des chemins cassés, je vois un 500:

helpers [27/Oct/2009:15:54:59 -0400] "GET /admin/member_photos/photos HTTP/1.1" 500 20 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3"

rack_hoptoad

J'ai également installé et configuré le middleware rack_hoptoad dans mon fichier config.ru, mais aucune exception ne se produit. à charger.

# Send exceptions to hoptoad
require 'rack_hoptoad'
use Rack::HoptoadNotifier, 'MY_API_KEY'

enregistrement

J'ai mis en place la journalisation comme si ..

set :raise_errors => true
set :logging, true

log = File.new("log/sinatra.log", "a+")
STDOUT.reopen(log)
STDERR.reopen(log)

require 'logger'
configure do
  LOGGER = Logger.new("log/sinatra.log") 
end

helpers do
  def logger
    LOGGER
  end
end

Cette configuration me permet d’appeler logger.info dans mes itinéraires, ce qui fonctionne localement et sur le serveur pour les itinéraires de travail, mais les chemins cassés ne vont pas assez loin pour appeler logger.info.

Que faire?

Des idées sur la façon dont je peux voir ce qui cause les 500 erreurs? Merci pour toute aide!

Answer 1

J'essaierais d'utiliser le middleware Rack :: ShowExceptions pour essayer de retracer le problème. Dans votre config.ru, ajoutez ces deux lignes avant l'appel d'exécution:

require 'rubygems'
require 'your-app'

use Rack::ShowExceptions

run YourApp

Cela devrait capturer et afficher la trace de trace pour toute exception se produisant dans Rack ou dans votre application. Cela devrait vous donner plus de détails, au moins ce serait l’espoir.

Answer 2

Peut-être qu'il y a quelque chose qui ne va pas dans la configuration de votre journal?

Redirigez STDERR lors de l’exécution du serveur Sinatra afin que vous puissiez le lire. J'aime:

ruby myapp.rb -p 1234 > log/app.log 2>&1

Answer 3

Merci pour les réponses, mais je n'ai pas eu besoin de les utiliser. À l'origine, je déployais l'application dans une configuration de sous-URI . . Lorsque j'ai déployé l'application sur son propre sous-domaine, les problèmes ont disparu.

Alors ... je ne sais pas trop quel était le problème, mais ma solution Apache pour le site a été résolue: voici ce qui a résolu le problème:

Redirect permanent / https://www.example.org/admin/member_photos/