Daemon processes

Skip to first unread message

Taru Karttunen

Jan 4, 2010, 7:35:12 AM1/4/10
to golang-nuts

Has anyone hacked together support for creating daemons
with Go? This seems quite hard to do since forking
is non-trivial (e.g. with pakackage init-functions
spawning new go-routines).

- Taru Karttunen


Jan 4, 2010, 8:30:53 AM1/4/10
to Taru Karttunen, golang-nuts
2010/1/4 Taru Karttunen <tar...@taruti.net>:

Can't you just make a program and then make a script to launch
multiple instances of it or background it etc.?

- jessta

Charle Demers

Feb 6, 2010, 7:00:46 PM2/6/10
to golang-nuts
From what I understand, the go routines will always be terminated when
the main exits. As an alternative, and I don't know if it's a good
practice, but I guess you could use the RawSyscall function to access
the usual fork() :

r1, r2, err1 = RawSyscall(SYS_FORK, 0, 0, 0)

- Charle Demers

Charle Demers

Feb 6, 2010, 9:28:32 PM2/6/10
to golang-nuts
And for good measure... I wrapped this in a function, ready to use.

import (

func main() {
var pid, err uintptr

pid, err = fork();

// pid = 0, I'm the child, pid != 0, I'm the parent and pid is the
child process pid.

if err != 0 {


func fork() (pid uintptr, err uintptr) {
var r1, r2, err1 uintptr

darwin := syscall.OS == "darwin"

r1, r2, err1 = syscall.RawSyscall(syscall.SYS_FORK, 0, 0, 0)

if err != 0 {
return 0, err1

// Handle exception for darwin
if darwin && r2 == 1 {
r1 = 0;

return r1, 0


- Charle Demers

Russ Cox

Feb 7, 2010, 12:54:55 AM2/7/10
to Charle Demers, golang-nuts
On Sat, Feb 6, 2010 at 18:28, Charle Demers <charle...@gmail.com> wrote:
> And for good measure... I wrapped this in a function, ready to use.

This won't work reliably in a real program. Once you've started
another thread, fork+exit in parent is either wrong or impossible,
depending on the operating system. Since imported packages
can start goroutines as part of initialization, and those will likely
cause new threads to be created soon after starting main, just
calling fork is not going to work in general.

By far the easiest solution for now is to use the shell's & feature.
I think at some point there will be an os/background package
that you can import and then use to "fork" into the background,
but it is subtle. I tried to put it together a few weeks ago and
got stuck on some detail (I don't remember what) and set it aside.


Charle Demers

Feb 7, 2010, 1:02:12 PM2/7/10
to golang-nuts
Thanks Russ!

I'll check out this os/background package is ready.

Impressive work by the way, keep it up!


On Feb 7, 12:54 am, Russ Cox <r...@golang.org> wrote:

Joseph Stewart

Feb 24, 2010, 8:59:21 AM2/24/10
to golang-nuts
Could a general solution be to offer linker options to allow pre Go ("going") and post Go ("gone") functions to be called?

Maybe "6l [-A pre_go_fn ] [-Z post_go_fn ]"

This could allow the "close 0,1,2 / setuid / fork" to take place in an .o file all before Go was even aware it happened.

I'm imagining all kinds of OSX/win32 stuff for this too, but perhaps this is too messy a solution.

If this doesn't sound like utter trash to our benevolent Go overlords, I can give a go at prototyping this.



Steven Degutis

Aug 31, 2012, 12:16:56 AM8/31/12
to golan...@googlegroups.com, Charle Demers, r...@golang.org
Any news on this concept? Any merit to it?


Ryan Day

Aug 31, 2012, 1:44:09 AM8/31/12
to golan...@googlegroups.com, Charle Demers, r...@golang.org
I was interested in this idea awhile back as well, but now I am just using Upstart (on my Ubuntu system) and I would use a standard initscript on any others. Even when you get the program daemonized, you still have to monitor it. So why not just take advantage of a program like Upstart and just "service <prog> restart" after a build? (I'm sure there are valid reasons here, just not in my particular case).

Reply all
Reply to author
0 new messages