So I got it to work by recreating the config before the stop.I wrote a
little blog post about it here http://www.kennylovrin.com/?p=43 with my
Capistrano script as well.

Hopefully it can help someone else out!

Thanks a lot for the quick response Pat!

Kenny

2009/3/21 Pat Allan <[email protected]>

>
> Hmm, the start task doesn't generate the config file - only the
> indexing task does. So if you're calling that in the middle, then it
> could be a possibility, yeah. Because Sphinx needs the configuration
> file to know where the pid file is located (and thus which process to
> stop).
>
> --
> Pat
>
> On 21/03/2009, at 9:23 PM, Kenny Lövrin wrote:
>
> > Hey
> >
> > In fact, capistrano is using the same user as I am when I log in,
> > which in this case actually is root (I know, I know ;)). So that is
> > probably not the problem.
> >
> > This morning, I was thinking of a think I never tried yesterday. One
> > thing that seemed a bit weird to me is that the Capistrano tasks are
> > pretty much linking up the new release directory, meaning the config
> > files disappear, before it does the stop task. Then when it tries to
> > start again, it writes the new config.
> >
> > At first glance that looked a bit strange to me, but I didn't
> > reflect on it at the time. My reasoning around this is:
> >
> > Cap tries to stop, it looks ok, but it doesnt stop sphinx
> > Cap tries to start sphinx by first creating a config, then starting,
> > and it fails because searchd is stil running
> > I log into the server and manually stop, and it works.
> >
> > Can this be because the config file is missing when Cap tries to
> > stop, but it is created by the failing start task, so it works when
> > I log in manually?
> >
> > Thanks
> > Kenny
> >
> > 2009/3/21 Pat Allan <[email protected]>
> >
> > Hi Kenny
> >
> > Is capistrano running with the same user details as you're using when
> > you manually log in to the server and run rake tasks? It could be a
> > permissions issue, which is perhaps why Sphinx isn't stopping and/or
> > the pid file remains.
> >
> > --
> > Pat
> >
> > On 21/03/2009, at 9:43 AM, kennylovrin wrote:
> >
> > >
> > > Hey friends
> > >
> > > I looked into Sphins and Thinking Sphinx for the first time today,
> > and
> > > so far it has been fairly painless and nice to work with.
> > >
> > > I have one problem though, and that is the restarting of sphinx via
> > > the rake tasks provided by TS, during a deploy with help of
> > > Capistrano.
> > >
> > > I based my deployment script on the one supplied on the Updrift
> > blog,
> > > and while it runs as it should, the outcome doesn't seem to be
> > really
> > > right.
> > >
> > > The problem I'm having is that when capistrano is about to restart
> > > sphinx after the code update, before the server restart, it runs the
> > > ts:stop task, and returns info saying that the searchd (lets assume
> > > pid 666) was stopped, then it tries to create the configuration file
> > > and start searchd again. When it tries to start, it says searchd is
> > > already running, and fails.
> > >
> > > If I then manually log into my server, I can go to my current
> > release
> > > dir and manually run ts:stop and it says it stopped searchd with pid
> > > 666. After that I can successfully start the searchd again.
> > >
> > > I have been looking over my rake tasks for quite some time, and can
> > > find no differences between mine and the one on the Updrift blog.
> > > Finally I resorted to splitting the tasks, manually stopping,
> > > deploying, starting.
> > >
> > > Anyone have a clue why it behaves like this?
> > >
> > > Thanks,
> > > Kenny
> > >
> > > >
> >
> >
> >
> >
> >
> > >
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/thinking-sphinx?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to