<p>I'm using Go to handle websockets. It's started with systemd as:</p>
<pre><code>[Unit]
Description=ODC websocket binary in Go
Requires=vagrant.mount
After=network.target vagrant.mount
[Service]
Type=simple
ExecStart=/vagrant/go/bin/odc
Restart=on-abort
[Install]
WantedBy=multi-user.target vagrant.mount
</code></pre>
<p>After awhile, I can see that 6 of these processes are now running. Because of Go's baked in concurrency, I'm guessing this is a bad thing, especially if all these processes want to respond to the same port?</p>
<p>Does anyone else have this issue, or is it not really an issue at all?</p>
<hr/>**评论：**<br/><br/>pdffs: <pre><p>How are you seeing that 6 processes are running? Do they actually have the same PID? If so, you're just seeing threads, not separate processes.</p></pre>asdf072: <pre><p>That's what I was thinking, but they each have their own PID. However, if I use htop and group them, they all fall under what looks like a master process, so I think they are go concurrency at work. Like you said, I didn't think they'd have separate PID's.</p></pre>st3fan: <pre><p>Threads also have a pid. Htop will show threads in green. If that is hard to see, enable the TGID column, which should be the PID of the process that owns the thread.</p></pre>CrackerJackMack: <pre><p>This is not a systemd issue or even an issue at all I don't believe. Go spawns <a href="https://rakyll.org/scheduler/" rel="nofollow">multiple threads to "balance"</a> work across multiple cores. When you do <code>systemctl status odc.service</code> you should see one parent process (bottom) and 5 children (above).</p>
<p>Even if you didn't stop your main() from exiting the Restart=on-abort shouldn't spawn perpetually. on-failure is typically the desired setting.</p></pre>
