Clone this repo:


  1. 3d9f6e0 Merge pull request #23 from VividCortex/nop-windows by Fernando · 1 year, 6 months ago master
  2. 267d8fa No-op windows support, providing GetExecutablePath utility func by Fernando Papa · 1 year, 6 months ago
  3. 560bd39 Merge pull request #19 from VividCortex/18-progname by Gustavo Kristic · 2 years, 9 months ago
  4. a2f1e2f Add ProgramName option to set os.Args[0] for the child by Gustavo Kristic · 2 years, 9 months ago
  5. 0c928cb Merge pull request #15 from VividCortex/inherit-flock by Gustavo Kristic · 2 years, 11 months ago


Daemonize Go applications with exec() instead of fork(). Read our blog post on the subject.

You can‘t daemonize the usual way in Go. Daemonizing is a Unix concept that requires some specific things you can’t do easily in Go. But you can still accomplish the same goals if you don't mind that your program will start copies of itself several times, as opposed to using fork() the way many programmers are accustomed to doing.

It is somewhat controversial whether it‘s even a good idea to make programs daemonize themselves, or how to do it correctly (and whether it’s even possible to do correctly in Go). Read here, here, and here for more on this topic. However, at VividCortex we do need to run one of our processes as a daemon with the usual attributes of a daemon, and we chose the approach implemented in this package.

Because of the factors mentioned in the first link just given, you should take great care when using this package‘s approach. It works for us, because we don’t do anything like starting up goroutines in our init() functions, or other things that are perfectly legal in Go in general.

Getting Started

View the package documentation for details about how it works. Briefly, to make your program into a daemon, do the following as soon as possible in your main() function:

import (

func main() {

Use the CaptureOutput attribute if you need to capture your program‘s standard output and standard error streams. In that case, the function returns two valid readers (io.Reader) that you can read from the program itself. That’s particularly useful for functions that write error or diagnosis messages right to the error output, which are normally lost in a daemon.

Use the Files attribute if you need to inherit open files into the daemon. This is primarily intended for avoiding race conditions when holding locks on those files (flocks). Releasing and re-acquiring locks between successive fork calls opens up the chance for another program to steal the lock. However, by declaring your file descriptors in the Files attribute, MakeDaemon() will guarantee that locks are not released throughout the whole process. Your daemon will inherit the file still holding the same locks, with no other process having intervened in between. See the package documentation for more details and sample code. (Note that you shouldn't use this feature to inherit TTY descriptors; otherwise what you get is technically not a daemon.)


Contributions are welcome. Please open pull requests or issue reports!


This repository is Copyright (c) 2013 VividCortex, Inc. All rights reserved. It is licensed under the MIT license. Please see the LICENSE file for applicable license terms.


The primary author is Gustavo Kristic, with some documentation and other minor contributions by others at VividCortex.


An earlier version of this concept with a slightly different interface was developed internally at VividCortex.


A Go Daemon is a good thing, and so we present an angelic cat picture:

Angelic Cat