Daemons gem, Ruby daemonize, directory weirdness

Posted: 2 years ago (2009-07-20 19:00:12 UTC )

There's a great ruby script called "daemonize", which got rolled into the "Daemons" rubygem. The idea is that if you want a pidfile and the ability to use Ubuntu style startup commands (mydaemon start, mydaemon stop, etc), you can just write a couple of lines of code to invoke your ruby script, and all's well.

Mostly, it works surprisingly well.

There are a couple of gotchas. First, it uses "load" by default to load your code, so it has to be Ruby, or you have to use its ":mode => :exec" option to use "exec".

Second gotcha: it runs from the root directory, so you need to give your script name as an absolute path.

Second-and-a-half gotcha: that applies to all command-line parameters as well.

Gotcha number 2.5, there, is especially annoying because you may not be invoking your daemonized Ruby script from, you know, Ruby. Instead, there's a decent chance you're doing it from bash. That's fine if you're actually physically typing, or if you're writing a script specific to your current machine, but it's annoying if you need to run bash commands to get the absolute directory of a non-executable file, and then strip off the newline from your command output, which turns out to be important.

I basically just did that from Ruby. It reduced the generality of the resulting script (can't use different command-line parameters), but kept me from having to do even basic string surgery in bash.

If I wanted to submit a patch to the daemons gem, I could get it to run the script from its own directory. That would have the advantage of being able to give non-absolute pathnames for the executable *and* its command-line parameters. They actually do that for the pidfile, which is nice, but then don't actually change to that directory so it doesn't work for command-line parameters.

They may have a reason for doing it the way they do, but it's not obvious to me what that reason would be.