忽略umask的Upstart `unicorn`

Question

我正在使用名为unicorn的upstart v1.4启动我的应用服务器。

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

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

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

Answer 1

“独角兽”在创业环境之外的表现如何？我猜是完全一样的，但请检查这个(保持一切都尽可能简单)。

请记住，umask值不是绝对值:顾名思义，它是一个掩码-当应用程序打开文件或创建目录时，它会从应用程序指定的权限位中“减去”权限位。据我所知，Upstarts umask stanza的表现一定是这个独角兽应用程序的问题，它在打开要写入的文件和创建目录时，指定了一组奇怪的权限位(模式)。

尝试使用stracing unicorn来查看它实际在做什么：

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

在等待unicorn创建一些文件和/或目录后，停止/终止它，并查看文件/tmp/strace.log. grep中的" open ( file )“，其中FILE是它创建的一个文件的名称，例如，并查看open系统调用的第三个参数是什么。当你有了这个mode值，你应该可以构造一个umask值来给你想要的文件权限。请注意，这确实假设unicorn：

umask与它不调用chmod(2)/fchmod(2). (2)本身的模式是一致的(这将覆盖

• 节)。
• 不调用umask

如果--在遵循了上面的过程之后--您仍然认为Upstart有问题，请提供一个简单的测试用例(不需要独角兽)，并在这里引发一个bug：https://bugs.launchpad.net/upstart/+filebug。

Answer 2

如果您不是从exec节中调用unicorn，而是调用一个只调用"umask >> /tmp/somefile“的脚本，它会在其中放入什么内容？如果这给出了预期的响应，那么您的问题出在unicorn中。