Christos Trochalakis wrote: > Ok, this is my theory, systemd correctly passes the sockets and the > environment to the process, but Amir is using rvm which probably runs > one more exec than usual. In this extra step rvm/ruby closes the fds for > security reasons but the ENV variables remain. In the newly forked ruby > process the timer gets fd=3 (which is now consider internal) and when > unicorn tries to example fd=3 breaks.
Very plausible! I ran a few straces to confirm at least part of the theory, and it turns out RVM runs not one, but 20 more exec than usual. :) The way my application is launched with RVM: $ strace -c -e trace=execve /usr/local/rvm/bin/rvm default exec ruby -e '' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 21 16 execve ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 21 16 total Using system Ruby: $ strace -c -e trace=execve ruby -e '' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 1 execve ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 1 total Using RVM ruby without RVM wrapper: $ strace -c -e trace=execve /usr/local/rvm/rubies/default/bin/ruby -e '' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 1 execve ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 1 total I will try to run my app using the 3rd method and report back as soon as I can. Thanks, Amir
