Question

J'utilise upstart v1.4 pour démarrer mon serveur d'applications, il est appelé unicorn .

Le fichier de configuration de upstart ressemble à ceci:

description "Unicorn Application Server"

start on network
stop on runlevel [!2345]

umask 0003
setuid unicorn
setgid myproject
chdir /opt/myproject/

respawn

exec /opt/myproject/bin/unicorn --config-file /opt/myproject/config/unicorn.rb --env production

Il est essentiel que le processus exécuté avec 0774, qui est ug+rwxo+r, au moins pour les répertoires. Utilisateur et groupe sont partagés en tant que tels que le serveur nginx, le téléchargement, l'enregistrement du personnel, etc.

J'ai observé que les répertoires sont créés avec les mauvaises permissions:

drw-rw-r-- 2 unicorn       myproject        4096 2012-01-13 06:58 20120113-0658-7704-4676

Pour autant que je sache, rien dans mon application est à l'origine de cette.

D'après la fixation gdb au processus, et en appelant call umask(0), le umask efficace est 75 ou 0o113.

Voici la session de gdb:

root@1:/opt/myproject# cat ./tmp/pids/unicorn.pid 
7600

root@1:/opt/myproject# gdb
GNU gdb (GDB) 7.1-ubuntu

(gdb) attach 7600
Attaching to process 7600

(gdb) call umask(0)
$1 = 75

(gdb) call umask(75)
$2 = 0

(gdb) q
Quit anyway? (y or n) y
Detaching from program: /usr/local/bin/ruby, process 7600

root@1:/opt/myproject# ruby -e 'printf("%o\n", 75)'
113

Le umask 113 expliquerait les autorisations en cours pour 664, qui semble être ce que je vois.

Qu'est-ce que je fais mal ici, est Unicorn mauvaise conduite? arriviste est ma strophe ignorant? Dois-je définirez la strophe comme 003, pas 0003? Mon travail de session gdb et la syntaxe de %o printf() correcte?

Était-ce utile?

La solution

Comment fonctionne en dehors BEHAVE « licorne » d'un environnement Upstart? Je dirais exactement la même chose, mais s'il vous plaît vérifier (tout garder aussi simple que possible).

Rappelez-vous qu'une valeur umask n'est pas un absolu: comme son nom l'indique, il est un masque - il « Soustrait » bits d'autorisation de l'autorisation BITS votre application spécifie quand il ouvre un fichier ou crée un répertoire . strophe arrivistes umask se comporte de ce que je peux voir si votre problème doit être avec cette application licorne précisant ce qu'il vous un ensemble impair de bits d'autorisation (mode) quand il ouvre les fichiers pour l'écriture et crée des répertoires.

Essayez stracing licorne pour voir ce qu'il est en train de faire:

  strace -o /tmp/strace.log -fFv -s 1024 /opt/myproject/bin/unicorn --config-file ...

Après avoir attendu licorne pour créer des fichiers et / ou répertoires, arrêt / tuer et de regarder le fichier /tmp/strace.log. grep pour « open (FILE) » où fichier est le nom d'un des fichiers qu'il crée par exemple, et voir ce que le 3ème argument est à l'appel de système ouvert. Lorsque vous avez cette valeur de mode, il devrait être possible de construire une valeur umask pour donner les autorisations de fichier que vous désirez. Notez que cela ne suppose que la licorne:

  • est compatible avec le mode qu'il indique.
  • ne remet pas umask (2) lui-même (qui l'emporterait sur la strophe du Upstart).
  • ne remet pas chmod (2) / fchmod (2).

Si - après avoir suivant le processus ci-dessus - vous pensez toujours qu'il ya un problème avec Upstart, s'il vous plaît fournir un test de simple (qui ne nécessite pas de licorne) et soulever un bug ici: https://bugs.launchpad.net/upstart/+filebug .

Autres conseils

Si vous au lieu d'appeler la licorne de la strophe exec appeler un script qui appelle simplement « umask >> / tmp / somefile » Que faut-il mettre là-dedans? Si cela donne la réponse attendue, votre problème est dans la licorne.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top