<p>What have you guys found to be the best way to run a Go process in the background? My server runs CentOS 7, and I've been launching my Go applications in the console during development but now it's time to run them as a process.</p>
<p>I really like the way Forever works for Node.js - anything similar for Go? Also, are there any hiccups with this if my application is designed to be multithreaded? (Across multiple physical cores, not just concurrent).</p>
<hr/>**评论：**<br/><br/>anoland: <pre><p>I've settled on systemd. </p>
<p>I use debian/ubuntu on most of my systems and the writing is pretty much on the wall. I don't want to add any mental overhead to what I already have to keep track of.</p></pre>curiousGambler: <pre><p>Shit, you're right.</p>
<p>I just finished an init script for something... meh...</p></pre>benjica: <pre><p>The <a href="https://coreos.com/docs/launching-containers/launching/launching-containers-fleet/" rel="nofollow">CoreOS fleet model</a> has impressed upon me quite a bit. I use docker containers to isolate daemon related processes and Systemd to orchestrate processes in the context of a system as a whole. If there is no run time dependencies I will forego docker.</p>
<p>I even use Systemd in the <a href="https://wiki.archlinux.org/index.php/Systemd/User" rel="nofollow">user context</a> too!</p></pre>anoland: <pre><p>OK, using systemd in user context looks very nice. That gives me a compelling reason to start using it.</p></pre>cenuij: <pre><p>Aye agreed, use socket activation and you won't have to worry about dropping privs, run the daemon as any user/group.</p></pre>pierrrre: <pre><p>supervisor</p></pre>fknChaos: <pre><p>I use this at work and home.</p></pre>bourbondog: <pre><p>Haven't looked back after using this. I'm not sure how this compares to systemd though.</p></pre>mashmorgan: <pre><p>and it restart deamons unlike systemd ?</p></pre>pooogles: <pre><p>systemd can restart daemons on failure.</p></pre>dwevlo: <pre><p>I use this: <a href="http://www.badgerodon.com/socketmaster">http://www.badgerodon.com/socketmaster</a>, but I'm not sure I'd actually recommend it. (it lets me host multiple apps on the same machine and also handles graceful restarts)</p>
<p>Besides that I just use standard systemd. Create a file: <code>/etc/systemd/system/www.service</code>:</p>
<pre><code>[Unit]
Description=www
[Service]
ExecStart=/opt/www/www
WorkingDirectory=/opt/www
Restart=always
[Install]
WantedBy=multi-user.target
</code></pre>
<p>And just rsync your files to the server:</p>
<pre><code>[remote] $ systemctl stop www
[local ] $ rsync -az --delete /tmp/build-www/ {USER}@{MACHINE}:/opt/www
[remote] $ systemctl start www
</code></pre>
<p>To create <code>/tmp/build-www</code> I just make a new empty folder, build with <code>go build -o /tmp/build-www/www</code>, and copy over my assets folder.</p>
<p>Seems like there should be more to it, but there's really not. Systemd makes this very easy.</p></pre>warmans: <pre><p>Clearly init.d is the only sensible option for people that like writing hundreds of almost identical bash scripts.</p></pre>kardianos: <pre><p>I would recommend using the system service manager.
A way to do this across platforms, including Linux is: <a href="https://github.com/kardianos/service">https://github.com/kardianos/service</a></p></pre>kurin: <pre><p>This is a beautiful package, btw. It doesn't seem like much when you create a Linux service and, yeah, there's my init.d file, but then you can install the same code as a <em>Windows</em> service... now <em>that's</em> cool.</p></pre>bonekeeper: <pre><p>You can use Monit and get service restart for free if a crash occurs.</p></pre>Spirit_of_Stallman: <pre><p>I am use <a href="http://supervisord.org/">supervisor</a> (from debian repo). </p></pre>koffiezet: <pre><p>Docker, or use what your distro provides you. Most have something like <code>start-stop-daemon</code> which you can use in a simple init script.</p></pre>libertyaikido: <pre><p>runit</p></pre>radimm: <pre><p>+1 it can't get simpler than that. Using it both on Linux and BSD systems so I do appreciate the fact I can get it independent from specific init/control mechanisms of the target systems (looking at you linux distributions)</p>
<p>other benefit is handling of stdout directly. </p></pre>kpumukster: <pre><p>Use systemd + <a href="https://github.com/cupcake/mannersagain">https://github.com/cupcake/mannersagain</a> on Centos 7</p></pre>jamra06: <pre><p>So manners again will pass currently open http requests that are still being processed?</p></pre>kpumukster: <pre><p>Not exactly. Basically, it will fork, child assumes control over socket (accepts new connections), and asks parent to kill itself, which will wait till all currently open requests are finished, and die.</p></pre>jamra06: <pre><p>Ok cool. My worry was that it closed any pending requests. Since it doesn't, it's a good tool</p></pre>bketelsen: <pre><p>Mentioned already - but Docker really is a good way to do this. Since you're on centos7, systemd is your next best choice, easy to use & learn, lots of examples out there.</p></pre>shirro: <pre><p>It depends on your distro. With Centos I guess you have systemd. Use it. It was designed to handle a lot of the stuff that is hard with regular init even if it is controversial. Don't bother with writing any double fork daemon stuff. It is a pain in Go and not worth it.</p>
<p>I haven't moved to systemd yet so I am using init scripts and monit to monitor and restart. And a c-wrapper to handle the daemon stuff like <a href="https://github.com/fiorix/go-daemon" rel="nofollow">https://github.com/fiorix/go-daemon</a> which can log std output and take a signal for log rotation and can passes on signals to something like <a href="https://github.com/tylerb/graceful" rel="nofollow">https://github.com/tylerb/graceful</a> for graceful shutdown of http.</p></pre>VoidByte: <pre><p>Please as an ex-sysadmin run it properly. Figure out what your system uses to manage its daemons. Use that.</p>
<p>Systemd, upstart, sysvinit, what ever it is just use it. Way way better to nohup, or screen or any of these other solutions.</p>
<p>If you don't want to do that look into something like daemontools, runit, or even <em>shudders</em> god.</p></pre>plafoucr: <pre><p>docker :)</p></pre>aterlumen: <pre><p>There's dozens of us!</p></pre>anoland: <pre><p>Literally!</p></pre>therealgato: <pre><p>try <a href="https://github.com/tekii/soju" rel="nofollow">https://github.com/tekii/soju</a> It handles the signals to stop all working gorutines and we been using it with upstart for 2 years with no issue</p></pre>itsmontoya: <pre><p>I love using systemd when it's available. When it isn't, I usually just write a bash script. Although you can pipe your stdout using bash, I like to capture my stdout and stderr using <a href="https://github.com/missionMeteora/oBandit" rel="nofollow">oBandit</a> (Insert shameless plug here)</p></pre>ston1th: <pre><p>Use go-daemon: <a href="https://github.com/sevlyar/go-daemon" rel="nofollow">https://github.com/sevlyar/go-daemon</a> for a deamon binary.</p>
<p>EDIT:
If you want to have the job done by a wrapper you can use nohup, screen, start-stop-daemon or systemd (wich are not portable to other systems like *BSD or UNIX)</p></pre>miah_: <pre><p>Don't understand why this is getting all the downvotes. It actually answers the question.</p></pre>ston1th: <pre><p>Well there goes the EDIT.</p></pre>siimphh: <pre><p>Because it also needlessly dismisses systemd.</p></pre>miah_: <pre><p>No. Neither I or ston1th dismissed systemd. Its an init process. It can be used to manage non-forking processes and daemons. But it does not magically make your software a daemon. The question was 'how do I make my golang program a daemon', not 'how do I run a process so that it doesnt terminate'. If we were just wanting to run a process forever, <code>nohup</code> is also a suitable answer, but it still does <em>not</em> answer OP's question about making a go process a daemon.</p>
<p><a href="http://man7.org/linux/man-pages/man3/daemon.3.html" rel="nofollow">http://man7.org/linux/man-pages/man3/daemon.3.html</a></p>
<p><a href="https://en.wikipedia.org/wiki/Daemon_%28computing%29" rel="nofollow">https://en.wikipedia.org/wiki/Daemon_%28computing%29</a></p></pre>autowikibot: <pre><h5> </h5>
<h6> </h6>
<h4> </h4>
<p><a href="https://en.wikipedia.org/wiki/Daemon%20%28computing%29" rel="nofollow"><strong>Daemon (computing)</strong></a>: <a href="#sfw" rel="nofollow"></a> </p>
<hr/>
<blockquote>
<p>In <a href="https://en.wikipedia.org/wiki/Computer_multitasking" rel="nofollow">multitasking</a> computer <a href="https://en.wikipedia.org/wiki/Operating_system" rel="nofollow">operating systems</a>, a <strong>daemon</strong> (/ˈdiːmən/ or /ˈdeɪmən/) is a <a href="https://en.wikipedia.org/wiki/Computer_program" rel="nofollow">computer program</a> that runs as a <a href="https://en.wikipedia.org/wiki/Background_(computer_software)" rel="nofollow">background</a> <a href="https://en.wikipedia.org/wiki/Process_(computing)" rel="nofollow">process</a>, rather than being under the direct control of an interactive user. Traditionally daemon names end with the letter <em>d</em>: for example, syslogd is the daemon that implements the system logging facility and sshd is a daemon that services incoming <a href="https://en.wikipedia.org/wiki/Secure_Shell" rel="nofollow">SSH</a> connections.</p>
<p>In a <a href="https://en.wikipedia.org/wiki/Unix" rel="nofollow">Unix</a> environment, the <a href="https://en.wikipedia.org/wiki/Parent_process" rel="nofollow">parent process</a> of a daemon is often, but not always, the <a href="https://en.wikipedia.org/wiki/Init" rel="nofollow">init</a> process. A daemon is usually either created by a process <a href="https://en.wikipedia.org/wiki/Fork_(operating_system)" rel="nofollow">forking</a> a child process and then immediately exiting, thus causing init to adopt the child process, or by the init process directly launching the daemon. In addition, a daemon launched by forking and exiting typically must perform other operations, such as dissociating the process from any controlling <a href="https://en.wikipedia.org/wiki/Tty_(Unix)" rel="nofollow">terminal</a> (tty). Such procedures are often implemented in various convenience routines such as <em>daemon(3)</em> in Unix.</p>
<p>Systems often start daemons at <a href="https://en.wikipedia.org/wiki/Booting" rel="nofollow">boot</a> time and serve the function of responding to network requests, hardware activity, or other programs by performing some task. Daemons can also configure hardware (like <a href="https://en.wikipedia.org/wiki/Udev" rel="nofollow">udevd</a> on some <a href="https://en.wikipedia.org/wiki/GNU/Linux" rel="nofollow">GNU/Linux</a> systems), run scheduled tasks (like <a href="https://en.wikipedia.org/wiki/Cron" rel="nofollow">cron</a>), and perform a variety of other tasks.</p>
<h1></h1>
<p><a href="https://i.imgur.com/aoofm3w.png" rel="nofollow"><strong>Image</strong></a> <a href="https://commons.wikimedia.org/wiki/File:Free_and_open-source-software_display_servers_and_UI_toolkits.svg" rel="nofollow"><sup>i</sup></a> - <em>Components of some Linux desktop environments which are daemons include D-Bus, NetworkManager (here called unetwork), PulseAudio (usound), and Avahi.</em></p>
</blockquote>
<hr/>
<p><sup>Interesting:</sup> <a href="https://en.wikipedia.org/wiki/Windows_service" rel="nofollow"><sup>Windows</sup> <sup>service</sup></a> <sup>|</sup> <a href="https://en.wikipedia.org/wiki/Background_process" rel="nofollow"><sup>Background</sup> <sup>process</sup></a> </p>
<p><sup>Parent</sup> <sup>commenter</sup> <sup>can</sup> <a href="/message/compose?to=autowikibot&subject=AutoWikibot%20NSFW%20toggle&message=%2Btoggle-nsfw+cr914gh" rel="nofollow"><sup>toggle</sup> <sup>NSFW</sup></a> <sup>or<a href="#or" rel="nofollow"></a></sup> <a href="/message/compose?to=autowikibot&subject=AutoWikibot%20Deletion&message=%2Bdelete+cr914gh" rel="nofollow"><sup>delete</sup></a><sup>.</sup> <sup>Will</sup> <sup>also</sup> <sup>delete</sup> <sup>on</sup> <sup>comment</sup> <sup>score</sup> <sup>of</sup> <sup>-1</sup> <sup>or</sup> <sup>less.</sup> <sup>|</sup> <a href="http://www.np.reddit.com/r/autowikibot/wiki/index" rel="nofollow"><sup>FAQs</sup></a> <sup>|</sup> <a href="http://www.np.reddit.com/r/autowikibot/comments/1x013o/for_moderators_switches_commands_and_css/" rel="nofollow"><sup>Mods</sup></a> <sup>|</sup> <a href="http://www.np.reddit.com/r/autowikibot/comments/1ux484/ask_wikibot/" rel="nofollow"><sup>Magic</sup> <sup>Words</sup></a></p></pre>kadel: <pre><p>Why not systemd? It is far more easier and elegant solution, then go-daemon.</p></pre>ston1th: <pre><p>Well but its not portable. I dont mind of Windows but you cant use it on *BSD or UNIX. With go-daemon it basically schould work. BTW. hundley10 asked for a daemon not a wrapper.</p></pre>k0k0l4l4: <pre><p>Systemd makes that easy, just make a proper service file.
An example of systemd service config and init.d examples for older RHEL/CentOS and Debian systems for a simple server can be found here: <a href="https://github.com/zaf/agitator/tree/master/init" rel="nofollow">https://github.com/zaf/agitator/tree/master/init</a></p></pre>james-h: <pre><p>I've been using <code>screen</code>.</p></pre>Xercoy: <pre><p>I also use screen, Would anyone know of any pros/cons to this? I've never had trouble with it, but at the same time I'm unaware of any alternatives. </p></pre>BraveNewCurrency: <pre><p>Running under screen is fine for one-time scripts that only have to run a little while. But running your production server under screen is bad:</p>
<p>First, if the box reboots, your service will not come back up. (Neither will your screen.)</p>
<p>Second, if your service crashes, it won't get restarted. Yes, crashes are rare. But even well-tested software has occasional problems (memory leak, corruption, etc.) Or sometimes some <em>OTHER</em> process has a memory leak and the OOM killer kills the wrong process.</p>
<p>Third, the process will inherit all your current environment variables. So you edit your .bashrc someday, and months later need to restart the server for the first time. Oops, it won't start because it relied on some value of a variable like $HOST or $HOME. Or someone else tries to start the process, but it doesn't work because some file is owned by the wrong person.</p>
<p>You need something like systemd (or Upstart) so that when you start the program, it's started the SAME (from a clean environment) no matter who starts it. </p>
<p>No need for ' fork into the background'. That code was annoying and very hard to get right anyway. Use a modern service like systemd/upstart/etc.</p></pre>james-h: <pre><p>That's very interesting. Thanks for sharing, I had no idea it had so many drawbacks.</p></pre>
