Is creating long running processes common?

<p>Is manually creating long running processes and managing things like pid files in Golang common? Wondering what the best practices are on this and log rotations in go, etc.</p> <hr/>**评论：**<br/><br/>Thaxll: <pre><p>Use systemd / upstart / supervisord for that.</p></pre>ericzhill: <pre><p>^ This. We deploy using <a href="https://cr.yp.to/daemontools.html" rel="nofollow">djb daemontools/supervise</a> and let multilog take care of the logging, rotation and cleanup. Our internal apps (built in Go) just use the plain <a href="https://golang.org/pkg/log/" rel="nofollow">log</a> package. The supervisor keeps the process running in the event it fails.</p> <p>This is by far the best way to keep long running processes up and going.</p></pre>benbjohnson: <pre><p>I don&#39;t do any PID or log management in my binaries. I leave that to the process manager (e.g. <em>systemd</em>).</p></pre>awhoof: <pre><p>So if you wanted to fork off several pieces of code (and distribute this thing to other users), would you have a make file that places the systemd files in the proper folder, and then just let the driver startup these processes (assuming you want to start and stop potential in bulk) with systemctl/systemd?</p></pre>carsncode: <pre><p>A huge benefit of Go is that it has no dependencies, so I tend to think of build very separately from install. I might have a makefile to produce a deb/rpm, which could create a service config, but I don&#39;t think I&#39;d have the makefile to so directly. Using makefiles as installers is more common with C/C++ apps, I don&#39;t think I&#39;ve ever seen a Go app published that way.</p></pre>awhoof: <pre><p>When distributing go, do you not create the executable and share that directly? I had no idea rpm could have the service files included. Also if it&#39;s an internal application is rpm really the way to go?</p></pre>carsncode: <pre><p>Have you ever installed a service from a package? It will create the service files, config files, data directories, log directories, etc.</p> <p>As far as when yo use it, it depends on the application. If installation is more involved than &#34;put this binary somewhere&#34; - eg when you need a service configuration for initd or systemd - then Linux packages or Windows installers are great tools, even for internal applications. If you need to automate software installation, why wouldn&#39;t you leverage the standard installation package for your platform? It&#39;s widely supported, widely understood, has extensive support in tools throughout the build/store/deploy pipeline, they cover upgrade and downgrade, and everyone using that platform is already familiar with them.</p> <p>Installation via makefile just adds unnecessary dependencies on both Go and make, at the least.</p></pre>stone_henge: <pre><blockquote> <p>Also if it&#39;s an internal application is rpm really the way to go?</p> </blockquote> <p>That depends on the alternative. You are going to have to distribute it somehow. If the installation is sufficiently complex you might benefit from using the functionality that the operating system already offers to manage installation, dependencies and configuration. Sometimes it&#39;s just a single binary you might as well drop in <code>$HOME/bin</code> though...</p></pre>packetlust: <pre><p>Yes, you should be building a package to be used by a package manager, and you should be putting that package into a local repository for your Linux machines to reach. Installation on the servers should be handled by &#34;yum install mypackage&#34; or &#34;apt install mypackage&#34; and nothing more complicated. That package should include any needed systemd/upstart/whatever files to make all the magic happen, and should have dependencies properly specified. You want ease of installation and repeatability for the people who admin the servers</p></pre>aboukirev: <pre><p>I&#39;ve done it two ways: an additional <code>install.sh</code> and self-install. The latter is <code>sudo</code> running executable with respective arguments (<code>install</code> commandl and options) to create a respective service file for <code>systemd</code>. It&#39;s not as flexible as one could wish but, given a limited set of environments I deploy to, it works and reduces number of files to deploy. You also don&#39;t need to run it like that and can configure everything manually if you wish.</p> <p>Using target system packaging (deb, rpm) is better because: - you may have dependencies on other packages - you can perform a clean removal or reinstall</p></pre>