<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Anchor Web Hosting Blog &#187; bash</title>
	<atom:link href="http://www.anchor.com.au/blog/tag/bash/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.anchor.com.au/blog</link>
	<description>A view into the Anchor Engineroom</description>
	<lastBuildDate>Thu, 29 Jul 2010 06:35:57 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Root cause analysis using shell history timestamping</title>
		<link>http://www.anchor.com.au/blog/2008/11/root-cause-analysis-using-shell-history-timestamping/</link>
		<comments>http://www.anchor.com.au/blog/2008/11/root-cause-analysis-using-shell-history-timestamping/#comments</comments>
		<pubDate>Tue, 18 Nov 2008 01:13:31 +0000</pubDate>
		<dc:creator>Barney Desmond</dc:creator>
				<category><![CDATA[FTW]]></category>
		<category><![CDATA[bash]]></category>
		<category><![CDATA[history]]></category>
		<category><![CDATA[log]]></category>
		<category><![CDATA[shell]]></category>
		<category><![CDATA[timestamp]]></category>
		<category><![CDATA[zsh]]></category>

		<guid isPermaLink="false">http://www.anchor.com.au/blog/?p=59</guid>
		<description><![CDATA[Some of the problem-solving we do has a forensic component (not in the legal sense). When something breaks down, we perform what&#8217;s known as Root Cause Analysis. It&#8217;s well and good to fix the symptoms so things are running again, but it&#8217;s more important to fix the problem so it doesn&#8217;t happen again. Often enough, [...]]]></description>
			<content:encoded><![CDATA[<p>Some of the problem-solving we do has a forensic component (not in the legal sense). When something breaks down, we perform what&#8217;s known as <a title="Wikipedia article on Root Cause Analysis" href="http://en.wikipedia.org/wiki/Root_cause_analysis">Root Cause Analysis</a>. It&#8217;s well and good to fix the symptoms so things are running again, but it&#8217;s more important to fix the problem so <em>it doesn&#8217;t happen again</em>.</p>
<p>Often enough, we&#8217;ll login to a user&#8217;s account and check out what they&#8217;ve run recently. They might have edited a config file, removed some necessary wrapper scripts (this happens on our shared hosting servers), or blindly duplicated something that really shouldn&#8217;t be copied. Whatever the case, these are good places to start looking when you need to fix something.</p>
<p><span id="more-59"></span></p>
<p>To check out the history, you can run the helpful `history` command. This is a small snippet, it&#8217;s not unreasonable to have a thousand entries or more.</p>
<blockquote>
<pre>hiroyuki@piffle:~% history
   60  mutt
   61  cd
   62  ssh shirayuki
   63  telnet sdf.lonestar.org
   64  cal -3
   65  cd ~/svn/puppet</pre>
</blockquote>
<p>Occasionally it&#8217;d be really helpful to know when a command was run. Did they delete any files around the time the problem started happening? When did they download an update for their CMS? Unfortunately, we usually don&#8217;t have an answer.</p>
<p>Thankfully this is easy to rectify. bash, the default shell on most systems, has the ability to record timestamps. If you&#8217;re one of those hip cats that use zsh, you&#8217;re also in luck.</p>
<p>For bash, it&#8217;s a one-liner addition to your ~/.bash_profile file</p>
<blockquote>
<pre>export HISTTIMEFORMAT='%Y-%m-%d %H:%M:%S  '</pre>
</blockquote>
<p>For zsh it&#8217;s a little bit more, and can go in your ~/.zshrc</p>
<blockquote>
<pre>HISTFILE=~/.zsh_history

HISTSIZE=9999

SAVEHIST=9999

setopt extendedhistory</pre>
</blockquote>
<p>Once you&#8217;ve set this up, you&#8217;ll need to re-open your shell so it reads in the changes. Go ahead and run a few commands. You might want to wait a couple of minutes so you can get distinct timestamps.</p>
<p>If you&#8217;re using bash, the history command will now print your timestamps.</p>
<blockquote>
<pre>misaki@piffle:~% history
   60  2008-11-18 08:38:24  mutt
   61  2008-11-18 08:39:46  cd
   62  2008-11-18 08:39:47  ssh shirayuki
   63  2008-11-18 08:43:13  telnet sdf.lonestar.org
   64  2008-11-18 08:45:06  cal -3
   65  2008-11-18 08:45:20  cd ~/svn/puppet</pre>
</blockquote>
<p>With zsh, you use `history -i` to display the timestamps.</p>
<blockquote>
<pre>charlotte@yoshino:~$ history -i
  116  2008-11-17 23:11:56  mv public_html/index.wsgi kita_he/
  117  2008-11-17 23:11:59  ls
  118  2008-11-17 23:12:07  cd kita_he/
  119  2008-11-17 23:12:07  ls
  120  2008-11-17 23:12:12  vim index.wsgi
  121  2008-11-17 23:16:32  psql</pre>
</blockquote>
<p>When you first enable timestamping you&#8217;ll notice it&#8217;s retroactively applied timestamps to every existing entry. While it&#8217;s not meaningful, you can&#8217;t do much about it, it needs something there for consistency and it&#8217;s unlikely to confuse anyone.</p>
<blockquote>
<p style="30px;"><em>We can solve problems</em></p>
<p style="30px;"><em>Using forensic science!</em></p>
<p style="30px;"><em>Timestamps are helpful.</em></p>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://www.anchor.com.au/blog/2008/11/root-cause-analysis-using-shell-history-timestamping/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
