New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
You should set the pid path via the command line... #7
Comments
Maybe a little explanation here? Not getting the case |
I converted a simple capistrano recipe to use unicorn via your gem. Every time I ran My I had to add Before I added the above line, I couldn't find a |
You can check out the example, https://github.com/sosedoff/capistrano-unicorn/blob/master/examples/rails3.rb I dont think its a good idea to pass unicorn pid directly via command line, easier just to define it in your unicorn config. |
Hmm.... if it could detect it was missing and complain, it would be good. An idea: In the code I just submitted, there is a Or maybe use a regex to see if it's set. Ideally, the |
Okay, here's how you can get the pidfile out of the configuration..... Assuming your real unicorn config file is
You just have to verify it's set to something and if it isn't, then raise a stink (or error) about it. |
Maybe I'm missing something because I'm not sure why this issue was closed - there seems to be a contradiction between the docs and actual out-of-the-box behaviour: If I create an empty unicorn config file and do Furthermore, if So please can you reopen until this is fixed? Thanks! |
Alright, reopening. Having something like generating the unicorn config file on the fly (in case if it does not exist) will help to get it started with zero configuration. |
Thanks ;-) |
But that still won't fix the violation of the two core principles mentioned above, e.g. if the unicorn config already existed, or if either the unicorn config or capistrano config are modified so that the pid paths no longer match. |
@sosedoff, @sfsekaran: the trick proposed by @docwhat above for automatically extracting the path to the pid file works great for me. However, there is the remaining question of whether it should be run client-side or server-side. It depends on knowing the path to the unicorn config file, which is currently calculated server-side at deploy time. So we can either:
I think the 2nd option would result in much cleaner code (and allow extending my
there would be no way to make auto-detection work, so at this point the code could simply fall back to the existing sensible default value, i.e. Thoughts? |
That sounds reasonable. The nice part about this feature is it's mostly unobtrusive to our users, so we can switch it to option 1 if 2 turns out to be a bust. |
Hmm, I just realised that doing it client-side would also require unicorn to be installed client-side, and maybe that's not a reasonable assumption. And if we went server-side instead, |
Ugh, server-side gets ugly fast due to |
(Sorry about the spam here, had to rebase a few times.) OK, I have a working fix for this - see #70. |
How this was finally solved? I keep getting the following error: I think it's still trying to detect PID on the client-side which sounds odd. Remote and local configuration may vary and since (I think) most users will send updates to the remote, staging/production servers the expected behaviour is: Capistrano loads and evaluates config vars >>> there <<< |
I ended up not using this plugin and creating a file on the server (in |
It'd be better if the pid path was set via the command line to match the value in the Capfile.
The text was updated successfully, but these errors were encountered: