Search code examples
ubuntupermissionsposixunicornupstart

Upstart `unicorn` with umask ignored

I'm using upstart v1.4 to start my application server, it's called unicorn.

The upstart configuration file looks like this:

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

It's essential that the process run with 0774, that is ug+rwxo+r, at least for directories. User & Group are shared as such as the nginx server, uploads, staff logging in, etc.

I have observed that the directories are created with the wrong permissions:

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

So far as I am aware, nothing in my application is causing this.

According to attaching gdb to the process, and calling call umask(0), the effective umask is 75, or 0o113.

Here's the gdb session:

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

The umask of 113 would account for permissions being made to 664, which appears to be what I'm seeing.

What am I doing wrong here, is Unicorn misbehaving? Is upstart ignoring my stanza? Should I be defining the stanza as 003, not 0003? Is my gdb session work, and %o printf() syntax correct?

Solution

  • How does "unicorn" behave outside of an Upstart environment? I would guess exactly the same but please check this (keep everything as simple as possible).

    Remember that a umask value is not an absolute: as the name suggests, it is a mask - it "subtracts" permission bits from the permission bits your application specifies when it opens a file or creates a directory. Upstarts umask stanza is behaving from what I can see so your problem must be with this unicorn application specifying what is to you an odd set of permission bits (mode) when it opens files for writing and creates directories.

    Try stracing unicorn to see what it is actually doing:

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

    Having waited for unicorn to create some files and/or directories, stop/kill it and look at file /tmp/strace.log. grep for "open(FILE)" where FILE is the name of one of the files it creates for example and see what the 3rd argument is to the open system call. When you have that mode value it should be possible to construct a umask value to give the file permissions you desire. Note that this does assume that unicorn:

    • is consistent with the mode it specifies.
    • does not call umask(2) itself (which would override the Upstart umask stanza).
    • does not call chmod(2)/fchmod(2).

    If -- after having following the process above -- you still think there is an issue with Upstart, please provide a simple test case (that does not require unicorn) and raise a bug here: https://bugs.launchpad.net/upstart/+filebug.