How to deal with panic output and logfiles (os.Stderr)

<p>Hi <a href="/r/golang">/r/golang</a>,</p> <p>I&#39;m using logrus in a web app to write to a logfile, but that doesn&#39;t log panics of course. So I thought maybe I can just override os.Stderr and os.Stdout to another file pointer, but that didn&#39;t work and panics are still on the original Stderr, not in the file.</p> <p>So how do you handle such cases?</p> <p>We&#39;re running on an old Debian 7 machine currently, so I could work around this by redirecting <code>start-stop-daemon --exec ...</code> output for now, but that&#39;s not really nice IMHO.</p> <hr/>**评论：**<br/><br/>bo-banane: <pre><p>Maybe I could insert a recover in my handler&#39;s wrapper and log the output. Hm, that&#39;s essentially what net/http does, right? I&#39;ll just have to retrieve the stack myself, since panic&#39;s return is a runtime.errorString (at least on nil dereferences).</p> <p>But I&#39;m still curious how you&#39;d handle this :)</p> <p>EDIT: That works, but I wonder if there&#39;s a nicer, more application wide solution, since this only targets the http handlers.</p></pre>QThellimist: <pre><p>I just looked at 30 - 40opensource projects most of them handle the same way you do including every big projects </p></pre>bo-banane: <pre><p>Such commitment :) Thanks for the feedback!</p></pre>defcube: <pre><p>This is how I&#39;m handling errors, but I admit I&#39;m new at go lang.</p></pre>no1youknowz: <pre><p>Any chance of a code snippet? Thanks</p></pre>bo-banane: <pre><p>Here&#39;s my handler type: <a href="https://gist.github.com/Knorkebrot/3fa97a3151cd99ca5fd4" rel="nofollow">https://gist.github.com/Knorkebrot/3fa97a3151cd99ca5fd4</a></p></pre>no1youknowz: <pre><p>Awesome!</p></pre>slrz: <pre><p>Just redirect the output from whatever starts your Go program. It&#39;s the most simple and straightforward thing to do. No idea why you consider it less nice than putting ugly workarounds into your code.</p> <p>When you upgrade your Debian 7 machine to Jessie, note that systemd captures a daemon&#39;s stderr by default and you can change it to go whereever you like by using the StandardError directive.</p></pre>bo-banane: <pre><p>Because that makes the log file depend on the starting mechanism and unconfigurable. I use wrapper scripts for third party software that can&#39;t log to a file usually, since that makes it independent of the init system used.</p></pre>slrz: <pre><p>A wrapper script for capturing panics is fine, too, I think. Those, like the init system approach, also include unrecoverable panics, which (as the name says) you can&#39;t recover from. When an unrecoverable panic happens, there might be no way to safely run arbitrary Go code, so they can&#39;t be logged using your favorite logging system but instead just get written out to fd2/stderr. And the most straightforward way to make writes to file descriptor 2 go where you want them to go is for the parent process to arrange it that way.</p> <p>If you insist on doing it inside your process, you could try it with dup2[0]. Still, I think it&#39;s way more sane to do it in the parent, so that it&#39;s obvious what&#39;s happening.</p> <p>[0] <a href="http://play.golang.org/p/9dfIMJ8UVM" rel="nofollow">http://play.golang.org/p/9dfIMJ8UVM</a></p></pre>