Has anyone managed to get capistrano to restart a jetty on a RHEL server?
I can not get it to work, and I'm not sure why. However capistrano is executing commands, the jetty that gets started up seems somehow tied to the capistrano session, and ends up getting killed when cap logs out of the remote server.
Just trying (run "#{sudo} /etc/init.d/jetty restart"). No errors are reported, but jetty is not running. If I add a "&& sleep 60" on the end, then jetty is started up and runs as long as the sleeping is happening, then it's gone.
I've tried setting :pty => true and :shell => true, neither/both seems to make a difference.
Anyone managed to figure this out, or have any clues?
I struggled with something like this as well. In my case, it was strying
to start solr (using jetty). The difference is, we start it using phing,
but here's how I did it:
> nohup phing solr-start > /dev/null 2> /dev/null
The trick seemed to be starting it with nohup and redirecting stdout and
stderr to /dev/null. This allows it to disconnect from the capistrano
session and continue running in the background.
On Thu, Sep 27, 2012 at 1:52 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote:
> Has anyone managed to get capistrano to restart a jetty on a RHEL server?
> I can not get it to work, and I'm not sure why. However capistrano is
> executing commands, the jetty that gets started up seems somehow tied to
> the capistrano session, and ends up getting killed when cap logs out of the
> remote server.
> Just trying (run "#{sudo} /etc/init.d/jetty restart"). No errors are
> reported, but jetty is not running. If I add a "&& sleep 60" on the end,
> then jetty is started up and runs as long as the sleeping is happening,
> then it's gone.
> I've tried setting :pty => true and :shell => true, neither/both seems to
> make a difference.
> Anyone managed to figure this out, or have any clues?
> --
> * You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> * To unsubscribe from this group, send email to capistrano+unsubscribe@**
> googlegroups.com <capistrano%2Bunsubscribe@googlegroups.com> For more
> options, visit this group at http://groups.google.com/** > group/capistrano?hl=en <http://groups.google.com/group/capistrano?hl=en>
Huh, I guess I'll mess with that. Anyone know why this seems to be neccesary with jetty, when it's not with other init.d scripts to start deamon? It's too bad to lose the output of the /etc/init.d/jetty in the cap output.
> I struggled with something like this as well. In my case, it was
> strying to start solr (using jetty). The difference is, we start it
> using phing, but here's how I did it:
> nohup phing solr-start > /dev/null 2> /dev/null
> The trick seemed to be starting it with nohup and redirecting stdout and
> stderr to /dev/null. This allows it to disconnect from the capistrano
> session and continue running in the background.
> On Thu, Sep 27, 2012 at 1:52 PM, Jonathan Rochkind <rochk...@jhu.edu
> <mailto:rochk...@jhu.edu>> wrote:
> Has anyone managed to get capistrano to restart a jetty on a RHEL
> server?
> I can not get it to work, and I'm not sure why. However capistrano
> is executing commands, the jetty that gets started up seems somehow
> tied to the capistrano session, and ends up getting killed when cap
> logs out of the remote server.
> Just trying (run "#{sudo} /etc/init.d/jetty restart"). No errors
> are reported, but jetty is not running. If I add a "&& sleep 60" on
> the end, then jetty is started up and runs as long as the sleeping
> is happening, then it's gone.
> I've tried setting :pty => true and :shell => true, neither/both
> seems to make a difference.
> Anyone managed to figure this out, or have any clues?
> --
> * You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> <mailto:capistrano@googlegroups.com>
> * To unsubscribe from this group, send email to
> capistrano+unsubscribe@__googlegroups.com
> <mailto:capistrano%2Bunsubscribe@googlegroups.com> For more options,
> visit this group at
> http://groups.google.com/__group/capistrano?hl=en > <http://groups.google.com/group/capistrano?hl=en>
> --
> *Todd Courtnage*
> Director of Cloud Computing
> --
> * You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> * To unsubscribe from this group, send email to
> capistrano+unsubscribe@googlegroups.com For more options, visit this
> group at http://groups.google.com/group/capistrano?hl=en
Okay, I doubt I'll ever get to the bottom of it, but I'm trying to figure out what's going on in the code anyway, which is leading me to reading Net::SSH api docs, etc. I probably wont' figure out anything useful out, but, hey, it's an education.
Can anyone familiar wtih the capistrano code tell me where in the cap code Net::SSH::Sessions get opened, and, if it isn't being opened in block form that closes itself after the block, where they get closed? Having trouble finding it. Thanks if anyone can give me a tip!
> Huh, I guess I'll mess with that. Anyone know why this seems to be
> neccesary with jetty, when it's not with other init.d scripts to start
> deamon? It's too bad to lose the output of the /etc/init.d/jetty in the
> cap output.
> On 9/27/2012 4:01 PM, Todd Courtnage wrote:
>> I struggled with something like this as well. In my case, it was
>> strying to start solr (using jetty). The difference is, we start it
>> using phing, but here's how I did it:
>> The trick seemed to be starting it with nohup and redirecting stdout and
>> stderr to /dev/null. This allows it to disconnect from the capistrano
>> session and continue running in the background.
>> On Thu, Sep 27, 2012 at 1:52 PM, Jonathan Rochkind <rochk...@jhu.edu
>> <mailto:rochk...@jhu.edu>> wrote:
>> Has anyone managed to get capistrano to restart a jetty on a RHEL
>> server?
>> I can not get it to work, and I'm not sure why. However capistrano
>> is executing commands, the jetty that gets started up seems somehow
>> tied to the capistrano session, and ends up getting killed when cap
>> logs out of the remote server.
>> Just trying (run "#{sudo} /etc/init.d/jetty restart"). No errors
>> are reported, but jetty is not running. If I add a "&& sleep 60" on
>> the end, then jetty is started up and runs as long as the sleeping
>> is happening, then it's gone.
>> I've tried setting :pty => true and :shell => true, neither/both
>> seems to make a difference.
>> Anyone managed to figure this out, or have any clues?
>> --
>> * You received this message because you are subscribed to the Google
>> Groups "Capistrano" group.
>> * To post to this group, send email to capistrano@googlegroups.com
>> <mailto:capistrano@googlegroups.com>
>> * To unsubscribe from this group, send email to
>> capistrano+unsubscribe@__googlegroups.com
>> <mailto:capistrano%2Bunsubscribe@googlegroups.com> For more options,
>> visit this group at
>> http://groups.google.com/__group/capistrano?hl=en >> <http://groups.google.com/group/capistrano?hl=en>
>> --
>> *Todd Courtnage*
>> Director of Cloud Computing
>> --
>> * You received this message because you are subscribed to the Google
>> Groups "Capistrano" group.
>> * To post to this group, send email to capistrano@googlegroups.com
>> * To unsubscribe from this group, send email to
>> capistrano+unsubscribe@googlegroups.com For more options, visit this
>> group at http://groups.google.com/group/capistrano?hl=en
> Okay, I doubt I'll ever get to the bottom of it, but I'm trying to figure
> out what's going on in the code anyway, which is leading me to reading
> Net::SSH api docs, etc. I probably wont' figure out anything useful out,
> but, hey, it's an education.
> Can anyone familiar wtih the capistrano code tell me where in the cap code
> Net::SSH::Sessions get opened, and, if it isn't being opened in block form
> that closes itself after the block, where they get closed? Having trouble
> finding it. Thanks if anyone can give me a tip!
> On 9/27/2012 4:19 PM, Jonathan Rochkind wrote:
>> Huh, I guess I'll mess with that. Anyone know why this seems to be
>> neccesary with jetty, when it's not with other init.d scripts to start
>> deamon? It's too bad to lose the output of the /etc/init.d/jetty in the
>> cap output.
>> On 9/27/2012 4:01 PM, Todd Courtnage wrote:
>>> I struggled with something like this as well. In my case, it was
>>> strying to start solr (using jetty). The difference is, we start it
>>> using phing, but here's how I did it:
>>> The trick seemed to be starting it with nohup and redirecting stdout and
>>> stderr to /dev/null. This allows it to disconnect from the capistrano
>>> session and continue running in the background.
>>> On Thu, Sep 27, 2012 at 1:52 PM, Jonathan Rochkind <rochk...@jhu.edu
>>> <mailto:rochk...@jhu.edu>> wrote:
>>> Has anyone managed to get capistrano to restart a jetty on a RHEL
>>> server?
>>> I can not get it to work, and I'm not sure why. However capistrano
>>> is executing commands, the jetty that gets started up seems somehow
>>> tied to the capistrano session, and ends up getting killed when cap
>>> logs out of the remote server.
>>> Just trying (run "#{sudo} /etc/init.d/jetty restart"). No errors
>>> are reported, but jetty is not running. If I add a "&& sleep 60" on
>>> the end, then jetty is started up and runs as long as the sleeping
>>> is happening, then it's gone.
>>> I've tried setting :pty => true and :shell => true, neither/both
>>> seems to make a difference.
>>> Anyone managed to figure this out, or have any clues?
>>> --
>>> * You received this message because you are subscribed to the Google
>>> Groups "Capistrano" group.
>>> * To post to this group, send email to capistrano@googlegroups.com
>>> * To unsubscribe from this group, send email to
>>> capistrano+unsubscribe@**googlegroups.com<capistrano%2Bunsubscribe@googlegr oups.com>For more options, visit this
>>> group at http://groups.google.com/**group/capistrano?hl=en<http://groups.google.com/group/capistrano?hl=en>
> --
> * You received this message because you are subscribed to the Google
> Groups "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> * To unsubscribe from this group, send email to capistrano+unsubscribe@**
> googlegroups.com <capistrano%2Bunsubscribe@googlegroups.com> For more
> options, visit this group at http://groups.google.com/** > group/capistrano?hl=en <http://groups.google.com/group/capistrano?hl=en>
