0

我upstart v1.4用来启动我的应用程序服务器，它被称为unicorn.

upstart配置文件如下所示：

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

进程必须使用 运行0774，也就是说ug+rwxo+r，至少对于目录来说是这样。用户和组是共享的，例如 nginx 服务器、上传、员工登录等。

我观察到目录是使用错误的权限创建的：

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

据我所知，我的应用程序中没有任何原因导致这种情况。

根据附加gdb到进程，调用call umask(0)，有效的 umask 是75， 或0o113。

这是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

的 umask113将说明对 的权限664，这似乎是我所看到的。

我在这里做错了什么，是独角兽行为不端吗？暴发户是否忽略了我的节？我应该将节定义为003，不是0003吗？我的gdb会话工作正常吗，%o printf()语法是否正确？

4

2 回答 2

1

如果您不是从 exec 节调用 unicorn，而是调用一个只调用“umask >> /tmp/somefile”的脚本，它会在其中放置什么？如果这给出了预期的响应，那么你的问题就出在独角兽身上。

于 2012-01-13T14:46:02.540 回答
1

“独角兽”在 Upstart 环境之外的表现如何？我猜完全一样，但请检查一下（让一切尽可能简单）。

请记住，umask 值不是绝对值：顾名思义，它是一个掩码——它从您的应用程序在打开文件或创建目录时指定的权限位中“减去”权限位。Upstarts umask 节的行为从我所见，所以你的问题一定是这个独角兽应用程序在打开文件进行写入和创建目录时指定对你来说是一组奇怪的权限位（模式）。

尝试 stracing unicorn 看看它实际上在做什么：

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

等待独角兽创建一些文件和/或目录后，停止/杀死它并查看文件/tmp/strace.log.grep 以获取“open(FILE)”，其中 FILE 是它创建的文件之一的名称，例如，查看第三个参数是什么打开系统调用。当您拥有该模式值时，应该可以构造一个 umask 值来授予您想要的文件权限。请注意，这确实假设独角兽：

  • 与它指定的模式一致。
  • 不调用 umask(2)本身（这将覆盖 Upstart umask 节）。
  • 不调用 chmod(2)/fchmod(2)。

如果 - 在遵循上述过程之后 - 您仍然认为 Upstart 存在问题，请提供一个简单的测试用例（不需要独角兽）并在此处提出错误：https ://bugs.launchpad.net/新贵/+filebug。

于 2012-01-16T10:09:16.043 回答