Question

我正在使用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，至少对目录而言。用户＆amp;群组是共享的，如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

如果您不是从exec节中调用独角兽，而是调用一个只调用＆＃34; umask＆gt;＆gt;的脚本。的/ tmp / somefile＆＃34;它放在那里什么？如果这给出了预期的响应，那么你的问题就在于独角兽。

Answer 2

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

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

尝试使用独角兽来看看它实际上在做什么：

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

等待独角兽创建一些文件和/或目录，停止/杀死它并查看文件/tmp/strace.log. grep for“open（FILE）”，其中FILE是它为其创建的文件之一的名称示例，看看第三个参数是开放系统调用。当您具有该模式值时，应该可以构造一个umask值来为您提供所需的文件权限。请注意，这确实假设为独角兽：

与其指定的模式一致。
不会调用umask（2）本身（它会覆盖Upstart umask节）。
不会调用chmod（2）/ fchmod（2）。

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

Umask的新贵`独角兽`被忽略了

2 个答案: