Fichiers journaux non écrits dans (Passager)

Localement, mon application fonctionne correctement et écrit dans ses journaux.

Mon serveur de production exécute CentOS avec un serveur Apache exécutant Passenger. En essayant de déboguer, j’ai remarqué que mes fichiers journaux n’étaient pas écrits. La première chose que j’ai faite a été chmod 0666 et quand j’ai découvert que cela ne fonctionnait pas, j’ai regardé mon journal Apache. J’ai trouvé ceci: Erreur Rails: Impossible d’accéder au fichier journal. Assurez-vous que /var/www/vhosts/mysite.com/rails/exp/releases/20091124020342/log/production.log existe et qu’il s’agit de chmod 0666. Le niveau de journalisation a été élevé à WARN et la sortie dirigée vers STDERR jusqu’au problème. c’est réglé.

(Note: je déploie avec capistrano)

Quoi qu’il en soit, j’ai fait une recherche sur Google et trouvé des gens qui disaient que c’était un problème avec SELinux, alors j’ai regardé les documents passagers et j’ai trouvé ceci: http://www.modrails.com/documentation/Users%20guide.html#_my_rails_application_8217_s_log_file_is_not_being_written_to

qui dit essentiellement faire ceci: chcon -R -h -t httpd_sys_content_t / chemin / vers / votre / rails / app

Cependant, lorsque je remplis le bon chemin, j’obtiens: Opération non prise en charge.

Assez déconcerté … des idées?

Quels sont les résultats de “ls -l” sur votre fichier journal? Sur Ubuntu, je dois m’assurer que les acl sont corrects sur les fichiers journaux. Je résout généralement cela en utilisant

sudo chown -R deploy:deploy /path/to/app

Déployer est l’utilisateur que le passager exécute.

J’ai rencontré le même problème avec mon serveur Ubuntu 10.x. Voici ce que j’ai appris lors du dépannage.

Comme mentionné précédemment et dans les documents, Passenger exécute les processus de rails ruby en tant que propriétaire du fichier config / environment.rb. À moins que vous n’ayez fait quelque chose de spécial, c’est généralement le même que le propriétaire de l’ensemble de votre répertoire d’application. Dans le cas d’un déploiement capistrano, il s’agit de l’utilisateur capistrano.
Si environment.rb appartient à root (probablement parce que vous le déployez en tant que root), le passager exécute les processus de rails comme «personne».

Vous pouvez voir quel utilisateur les processus sont exécutés via la commande top (ou toute autre technique).

Dans les deux cas – le mien est devenu le dernier – si les processus de rails ne peuvent pas écrire dans les fichiers journaux, rien ne s’affiche dans les journaux (duh). Rails ignorera cette erreur d’autorisation refusée et essaiera de traiter les requêtes normalement.

La solution consiste à s’assurer que les processus rails ruby s’exécutent en tant qu’utilisateur propriétaire de votre déploiement de rails, du fichier config / environment.rb et du répertoire et des fichiers de journaux.

Cela peut être soit une étape de configuration de deplyment pour traiter les fichiers et répertoires en question, soit une configuration d’Apache et lui dire d’exécuter le processus ruby en tant qu’utilisateur spécifique (par exemple, root au lieu de personne). Exécuter en tant que root n’est évidemment pas recommandé, mais si vous le faites pour quelque raison que ce soit et que vous avez besoin de voir les journaux de rails correctement écrits, vous pouvez le faire en ajoutant les éléments suivants:

 # in /etc/apache2/apache2.conf PassengerDefaultUser root

Si vous ne déployez pas en tant que root (ce qui est le cas sur un autre serveur que je possède), le scénario standard devrait être que le répertoire des applications rails appartient à cet utilisateur non root et que les passagers exécutent les processus de rails en tant que même utilisateur. . Et tout devrait fonctionner.

[1] http://www.modrails.com/documentation/Users%20guide%20Apache.html#_the_rails_application_reports_that_it_8217_s_unable_to_start_because_of_a_permission_error