<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>*JJ</title><link href="http://blog.jdotjdot.com/" rel="alternate"></link><link href="http://blog.jdotjdot.com/feeds/tag/restart.atom.xml" rel="self"></link><id>http://blog.jdotjdot.com/</id><updated>2014-04-10T00:00:00-04:00</updated><entry><title>Automatically restarting your process or server on crash</title><link href="http://blog.jdotjdot.com/2014/04/restarting-your-server-on-crash/" rel="alternate"></link><updated>2014-04-10T00:00:00-04:00</updated><author><name>JJ</name></author><id>tag:blog.jdotjdot.com,2014-04-10:2014/04/restarting-your-server-on-crash/</id><summary type="html">&lt;p&gt;While working with &lt;a href="http://github.com/lord"&gt;Robert&lt;/a&gt; on the &lt;a href="http://github.com/lord/doorbot"&gt;Doorbot&lt;/a&gt; webserver as part of our project to hook up the front door of Hacker School to the web, we ran across a small problem with the Ruby server that he had set&amp;nbsp;up.&lt;/p&gt;
&lt;p&gt;In the past, my sites have always been hosted places like Heroku or &lt;a href="http://www.webfaction.com?affiliate=thecampusrep"&gt;Webfaction&lt;/a&gt;, which take care of restarting the server in case of&amp;nbsp;shutdown.&lt;/p&gt;
&lt;p&gt;However, we were hosting the Doorbot server on a Raspberry Pi that we were planning to lock in the network closet.   This meant that no one was going to be able to get in there to physically unplug and replug the Pi, which is the method we&amp;#8217;d been using to restart the server after we (with great difficulty) got the server launch script into Raspbian&amp;#8217;s &lt;code&gt;init.d&lt;/code&gt; to start on startup.  Another method we&amp;#8217;d also been using was to &lt;span class="caps"&gt;SSH&lt;/span&gt; into the Pi to manually restart the server, but this of course wasn&amp;#8217;t a sustainable long-term solution.  If the server shut down on its own, people weren&amp;#8217;t going to be able to get through the door until someone alerted us and we restarted the server manually.   &lt;strong&gt;We needed a better solution that would automatically and reliably restart the server upon shutdown without any human&amp;nbsp;intervention.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;I suggested a strategy that I presented at a &lt;a href="https://github.com/jdotjdot/Data-Scraping-Talk--PennApps-F2012-"&gt;lecture&lt;/a&gt; at &lt;a href="http://pennapps.com"&gt;PennApps&lt;/a&gt; Fall 2012.   I had previously used this strategy on some web scraping projects to get a running Python process to restart immediately upon shutdown.  For processes like that scraper or the Ruby server, if the process dies with an error, we actually don&amp;#8217;t generally care in this case why it shut down or what the error was&amp;#8212;just that it shut down and that we want it back up&amp;nbsp;immediately.  &lt;/p&gt;
&lt;p&gt;The strategy is to &lt;strong&gt;wrap the server set-up process in a Bash script&lt;/strong&gt; within a &lt;code&gt;while&lt;/code&gt; or &lt;code&gt;until&lt;/code&gt; loop, as in the following example with my old Python&amp;nbsp;scraper:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span class="c"&gt;# Runs our scraper indefinitely&lt;/span&gt;
&lt;span class="c"&gt;# will only stop upon a GRACEFUL exit--&lt;/span&gt;
&lt;span class="c"&gt;#  but keep in mind a graceful exit only means that&lt;/span&gt;
&lt;span class="c"&gt;#  no error is thrown, but that doesn&amp;#39;t mean that we&lt;/span&gt;
&lt;span class="c"&gt;#  actually want the program to end!&lt;/span&gt;

&lt;span class="k"&gt;until &lt;/span&gt;python scraper.py; &lt;span class="k"&gt;do&lt;/span&gt;
&lt;span class="k"&gt;    &lt;/span&gt;&lt;span class="nb"&gt;echo&lt;/span&gt; &lt;span class="s2"&gt;&amp;quot;Process crashed with exit code $?.  Respawning...&amp;quot;&lt;/span&gt; &amp;gt;&amp;amp;2
    sleep 2
&lt;span class="k"&gt;done&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;


&lt;p&gt;For a server, you would replace &lt;code&gt;python scraper.py&lt;/code&gt; with &lt;code&gt;python manage.py runserver&lt;/code&gt; for Django, or the equivalent command in Ruby or your preferred web&amp;nbsp;framework.&lt;/p&gt;
&lt;p&gt;What happens here is the &lt;code&gt;until&lt;/code&gt; loop starts to test the &amp;#8220;condition,&amp;#8221; but the condition here is actually our intended process.  That process runs indefinitely, and ideally would never stop and we&amp;#8217;d never hit the &lt;code&gt;echo&lt;/code&gt;.  However, in the event that the server &lt;em&gt;does&lt;/em&gt; crash, we take advantage of a trick with Bash&amp;#8212;an exit upon failure will evalute &amp;#8220;false-y&amp;#8221; for the &lt;code&gt;until&lt;/code&gt; loop, and so on a crash, we will always enter and repeat the loop.  The only way to exit the loop is a successful server program exit, which will never happen, because we never intentionally shut down the&amp;nbsp;server!&lt;/p&gt;
&lt;p&gt;After wrapping the Ruby server startup call in that tiny Bash script, the server now automatically restarts itself upon&amp;nbsp;failure.&lt;/p&gt;</summary><category term="hackerschool"></category><category term="bash"></category><category term="doorbot"></category><category term="doorduino"></category><category term="server"></category><category term="crash"></category><category term="restart"></category></entry></feed>