There seem to be an issue with the darwin build:

package main
import (
    "github.com/VividCortex/godaemon"
    "os"
)
func main() {
    godaemon.MakeDaemon(&godaemon.DaemonAttr{})
    os.Exit(0)
}

I am using go 1.3

$ go version
go version devel +f613443bb13a Tue Apr 22 21:12:15 2014 -0700 linux/amd64

works fine on linux/amd64

$ go build godaemontest.go 
$ file godaemontest
godaemontest: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

fails on darwin/amd64

$ GOOS=darwin go build godaemontest.go
# github.com/VividCortex/godaemon
../go/bin/src/github.com/VividCortex/godaemon/daemon.go:62: undefined: GetExecutablePath

I successfully build other go binary for darwin/amd64 on my machine, so I doubt the issue is with the go tools.

Currently, we can't cross compile darwin on linux because it uses CGO. I think we could remove CGO entirely from that file and replace the current GetExecutablePath() function with:

func GetExecutablePath() (string, error) {
	return os.Executable()
}

If I'm missing something here please let me know, but I tested locally and it seems to be working. Happy to submit a PR if this is a suitable fix.

hi bro,
first thanks.
is it support windows?

The only Linux-specific thing in godaemon is reading /proc/self/exe to determine the program's true executable file. This can probably be gotten through os.Args[0] and some combination of path canonicalization, which I think there are helper functions for in the Go core libraries. Making this agnostic to Unix variant would be a good thing.

This happened twice:

2017/04/24 20:26:59 readlink /proc/self/exe: no such file or directory
2017/04/24 20:26:59 readlink /proc/self/exe: no such file or directory

and then my app is not daemonized

We're currently inheriting whatever the caller process has in os.Args. I propose an attribute to override it, if required.

github.com/VividCortex/godaemon

D:\golang\src\github.com\VividCortex\godaemon\daemon.go:157: cannot use fd (type
int) as type syscall.Handle in argument to syscall.CloseOnExec
D:\golang\src\github.com\VividCortex\godaemon\daemon.go:165: undefined: GetExecu
tablePath
D:\golang\src\github.com\VividCortex\godaemon\daemon.go:197: unknown syscall.Sys
ProcAttr field 'Setsid' in struct literal
D:\golang\src\github.com\VividCortex\godaemon\daemon.go:215: undefined: syscall.
Umask

It would be great to have automated tests that verify that our piped STDERR and STDOUT are working correctly.

I'm noticing inconsistent behavior between Linux distributions.

On Ubuntu/Debian, using the same (standard) SysVinit script, "service {name} stop" does not function as intended. The daemon is never killed during a stop() command. After much debugging, I've found that adding the final PID to /var/run{progName} corrects the stop() behavior.

On RedHat/CentOS, everything works as expected.

Of course, this likely comes down to differences in fallback mechanisms between the two distributions when the .pid file isn't present, but having a .pid file would go a long way to ensuring compatibility across Linux distributions.

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

The image is not loading.

Some what , some what want to see the cat picture.

Hi Guys!
I've been poking around looking for a good way to daemonize a function within our app I came across this. Most of the suggestions come down to "don't", and the existing libraries, namely https://github.com/sevlyar/go-daemon are pretty hacky and don't function properly.

This does seem to be missing one key feature that would make it perfect for us though. I need to be able to pass arguments and flags to the child process, rather than just run a new copy. I'm happy to try and add this feature if needed.

If you try to create a daemon that should run a single copy, and protects itself against multiple instances with a lock file, you may run into some difficulties. Trying to acquire the lock when you're already in the daemon stage provides very little feedback to the user, who should be able to see that he attempted to launch a second copy. But locking beforehand can also be a problem with the current implementation, cause you'd have to lock the file in every stage, thus opening the door to race conditions. We should allow to inherit files and their locks without an intermediate release.

Foma:godaemon juphoff$ go build

github.com/VividCortex/godaemon

./daemon_darwin.go:11: undefined: io
./daemon_darwin.go:12: missing return at end of function

It looks as if the offending function, DaemonizeWithCapture(), can be removed entirely; daemon_linux.go was refactored recently, and it does not contain a correspondingly named function:

Also, with it removed, building other agents on OS X turns up:

./vc-agent-007.go:168: undefined: godaemon.DaemonAttr
./vc-agent-007.go:169: undefined: godaemon.MakeDaemon

So it appears at least stubbing the Linux refactoring in daemon_darwin.go is necessary.

It is recommended to use the standard library function instead to remove the dependency on cgo.
Cross-compilation is also easier.

Daemons are not connected to consoles. Writing to standard output/error from such processes is useless at best. But, if you're unlucky enough, you could end up unintentionally writing to another file, socket, or whatever happens to occupy descriptor numbers 1 or 2. Even if you don't use os.Stdout and os.Stderr directly, you typically can't control what third-party packages do. Go's standard library has a bunch of prints to Go's log package, that defaults to standard error.

The ability to safely print (i.e., quietly ignore, with no side consequences) to standard output/error is required, so that eventual prints from libraries can't disrupt your current descriptors. Also, we want the ability to capture these streams, so that important information can be stored if required.

There are a few places in MakeDaemon() where os.Exit(1) is called when it determines it cannot daemonize() an app. In the cases where the calling app can still send output to stdout/stderr and possibly recover and run non-daemonized, these os.Exit(1) calls should be changed to error returns that the calling app can handle.

See #6 for more background information & discussion.

We found some underlying readlink(2) implementations to be failing on CentOS 5.10 (libc 2.5), sometimes returning a wrong number of bytes written to the buffer (see readlink()'s manual page). Used from C programs the error was not noticeable, cause we've also found the correct substring to be followed by a zero byte, thus effectively terminating the string for C. But Go doesn't care about zeros; there's no special string termination byte. Hence, os.Readlink() just continues till the indicated number of bytes and you end up including lots of garbage in the result. Even though readlink() is not required by POSIX to terminate the result with zero, for our usage it's worth attempting to work around this issue by looking if one is present anyway.