Pregunta

Estoy usando upstart v1.4 Para iniciar mi servidor de aplicaciones, se llama unicorn.

los upstart El archivo de configuración se ve así:

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

Es esencial que el proceso se ejecute con 0774, eso es ug+rwxo+r, al menos para directorios. El usuario y el grupo se comparten como el servidor NGINX, las cargas, el personal iniciar sesión, etc.

He observado que los directorios se crean con los permisos incorrectos:

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

Hasta donde sé, nada en mi aplicación está causando esto.

Según la fijación gdb al proceso, y llamando call umask(0), el ultmask efectivo es 75, o 0o113.

Aquí esta la gdb sesión:

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

El erask de 113 daría cuenta de los permisos que se hacen 664, que parece ser lo que estoy viendo.

¿Qué estoy haciendo mal aquí, el unicornio se está portando mal? ¿Upstart ignora mi estrofa? ¿Debería definir la estrofa como 003, no 0003? Es mi gdb trabajo de sesión, y %o printf() sintaxis correcta?

¿Fue útil?

Solución

¿Cómo se comporta el "unicornio" fuera de un entorno advenedizo? Supongo que es exactamente lo mismo, pero por favor verifique esto (mantenga todo lo más simple posible).

Recuerde que un valor de Umask no es absoluto: como su nombre lo sugiere, es una máscara: "resta" los bits de permiso De los bits de permiso, su aplicación especifica cuándo abre un archivo o crea un directorio. Upstarts Umask Stanza se está comportando de lo que puedo ver, por lo que su problema debe ser con esta aplicación de unicornio que especifica lo que es para usted un conjunto impar de bits de permiso (modo) cuando abre archivos para escribir y crear directorios.

Intente saquear unicornio para ver lo que realmente está haciendo:

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

Habiendo esperado a que Unicorn cree algunos archivos y/o directorios, deténgalo/mire y mire el archivo /tmp/strace.log. GREP para "Abrir (archivo)" donde el archivo es el nombre de uno de los archivos que crea, por ejemplo, y vea cuál es el tercer argumento para la llamada del sistema abierto. Cuando tenga ese valor de modo, debería ser posible construir un valor de Umask para dar los permisos de archivo que desea. Tenga en cuenta que esto supone que unicornio:

  • es consistente con el modo que especifica.
  • no llama a Umask (2) sí mismo (lo que anularía la estrofa de Umask Upstart).
  • no llama a chmod (2)/fchmod (2).

Si, después de tener el siguiente proceso anterior, todavía cree que hay un problema con Upstart, proporcione un caso de prueba simple (que no requiere unicornio) y plantee un error aquí: https://bugs.launchpad.net/upstart/+filebug.

Otros consejos

Si, en lugar de llamar a Unicornio desde la estrofa ejecutiva, llame a un script que solo llama "Umask >> /tmp /somefile" ¿Qué pone allí? Si eso da la respuesta esperada, su problema está en unicornio.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top