分类 技术志 下的文章

探索Go守护进程的实现方法

本文永久链接 – https://tonybai.com/2024/10/03/how-to-daemonize-go-program

在后端开发的世界里,守护进程(daemon)这个概念与Unix系统一样古老。守护进程是在后台运行的长期服务程序,不与任何终端关联。尽管现代进程管理工具如systemdsupervisor等让应用转化为守护进程变得十分简单,我们甚至可以使用以下命令来在后台运行程序:

nohup ./your_go_program &

但在某些情况下,程序的原生转化为守护进程的能力仍然是有必要的。比如分布式文件系统juicefs cli的mount子命令,它就支持以-d选项启动,并以守护进程方式运行:

$juicefs mount -h
NAME:
   juicefs mount - Mount a volume

USAGE:
   juicefs mount [command options] META-URL MOUNTPOINT

... ...

OPTIONS:
   -d, --background  run in background (default: false)
   ... ...
... ...

这种自我守护化的能力会让很多Go程序受益,在这一篇文章中,我们就来探索一下Go应用转化为守护进程的实现方法。

1. 标准的守护进程转化方法

W.Richard Stevens的经典著作《UNIX环境高级编程》中对将程序转化为一个守护进程的 (daemonize) 步骤进行了详细的说明,主要步骤如下:

  • 创建子进程并终止父进程

通过fork()系统调用创建子进程,父进程立即终止,保证子进程不是控制终端的会话组首领。

  • 创建新的会话

子进程调用setsid()来创建一个新会话,成为会话组首领,从而摆脱控制终端和进程组。

  • 更改工作目录

使用chdir(“/”) 将当前工作目录更改为根目录,避免守护进程持有任何工作目录的引用,防止对文件系统卸载的阻止。

  • 重设文件权限掩码

通过umask(0) 清除文件权限掩码,使得守护进程可以自由设置文件权限。

  • 关闭文件描述符

关闭继承自父进程的已经open的文件描述符(通常是标准输入、标准输出和标准错误)。

  • 重定向标准输入/输出/错误

重新打开标准输入、输出和错误,重定向到/dev/null,以避免守护进程无意输出内容到不应有的地方。

注:fork()系统调用是一个较为难理解的调用,它用于在UNIX/Linux系统中创建一个新的进程。新创建的进程被称为子进程,它是由调用fork()的进程(即父进程)复制出来的。子进程与父进程拥有相同的代码段、数据段、堆和栈,但它们是各自独立的进程,有不同的进程ID (PID)。在父进程中,fork()返回子进程的PID(正整数),在子进程中,fork()返回0,如果fork()调用失败(例如系统资源不足),则返回-1,并设置errno以指示错误原因。

下面是一个符合UNIX标准的守护进程转化函数的C语言实现,参考了《UNIX环境高级编程》中的经典步骤:

// daemonize/c/daemon.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <syslog.h>
#include <signal.h>

void daemonize()
{
    pid_t pid;

    // 1. Fork off the parent process
    pid = fork();
    if (pid < 0) {
        exit(EXIT_FAILURE);
    }
    // If we got a good PID, then we can exit the parent process.
    if (pid > 0) {
        exit(EXIT_SUCCESS);
    }

    // 2. Create a new session to become session leader to lose controlling TTY
    if (setsid() < 0) {
        exit(EXIT_FAILURE);
    }

    // 3. Fork again to ensure the process won't allocate controlling TTY in future
    pid = fork();
    if (pid < 0) {
        exit(EXIT_FAILURE);
    }
    if (pid > 0) {
        exit(EXIT_SUCCESS);
    }

    // 4. Change the current working directory to root.
    if (chdir("/") < 0) {
        exit(EXIT_FAILURE);
    }

    // 5. Set the file mode creation mask to 0.
    umask(0);

    // 6. Close all open file descriptors.
    for (int x = sysconf(_SC_OPEN_MAX); x>=0; x--) {
        close(x);
    }

    // 7. Reopen stdin, stdout, stderr to /dev/null
    open("/dev/null", O_RDWR); // stdin
    dup(0);                    // stdout
    dup(0);                    // stderr

    // Optional: Log the daemon starting
    openlog("daemonized_process", LOG_PID, LOG_DAEMON);
    syslog(LOG_NOTICE, "Daemon started.");
    closelog();
}

int main() {
    daemonize();

    // Daemon process main loop
    while (1) {
        // Perform some background task...
        sleep(30); // Sleep for 30 seconds.
    }

    return EXIT_SUCCESS;
}

注:这里省略了书中设置系统信号handler的步骤。

这里的daemonize函数完成了标准的守护化转化过程,并确保了程序在后台无依赖地稳定运行。我们编译运行该程序后,程序进入后台运行,通过ps命令可以查看到类似下面内容:

$ ./c-daemon-app
$ ps -ef|grep c-daemon-app
root     28517     1  0 14:11 ?        00:00:00 ./c-daemon-app

我们看到c-daemon-app的父进程是ppid为1的进程,即linux的init进程。我们看到上面c代码中转化为守护进程的函数daemonize进行了两次fork,至于为何要做两次fork,在我的《理解Zombie和Daemon Process》一文中有说明,这里就不赘述了。

那么Go是否可以参考上述步骤实现Go程序的守护进程转化呢?我们接着往下看。

2. Go语言实现守护进程的挑战

关于Go如何实现守护进程的转换,在Go尚未发布1.0之前的2009年就有issue提到,在runtime: support for daemonize中,Go社区与Go语言的早起元老们讨论了在Go中实现原生守护进程的复杂性,主要挑战源于Go的运行时及其线程管理方式。当一个进程执行fork操作时,只有主线程被复制到子进程中,如果fork前Go程序有多个线程(及多个goroutine)在执行(可能是由于go runtime调度goroutine和gc产生的线程),那么fork后,这些非执行fork线程的线程(以及goroutine)将不会被复制到新的子进程中,这可能会导致后续子进程中线程运行的不确定性(基于一些fork前线程留下的数据状态)。

理想情况下是Go runtime提供类似的daemonize函数,然后在多线程启动之前实现守护进程的转化,不过Go团队至今也没有提供该机制,而是建议大家使用如systemd的第三方工具来实现Go程序的守护进程转化。

既然Go官方不提供方案,Go社区就会另辟蹊径,接下来,我们看看目前Go社区的守护进程解决方案。

3. Go社区的守护进程解决方案

尽管面临挑战,Go社区还是开发了一些库来支持Go守护进程的实现,其中一个star比较多的解决方案是github.com/sevlyar/go-daemon。

go-daemon库的作者巧妙地解决了Go语言中无法直接使用fork系统调用的问题。go-daemon采用了一个简单而有效的技巧来模拟fork的行为:该库定义了一个特殊的环境变量作为标记。程序运行时,首先检查这个环境变量是否存在。如果环境变量不存在,执行父进程相关操作,然后使用os.StartProcess(本质是fork-and-exec)启动带有特定环境变量标记的程序副本。如果环境变量存在,执行子进程相关操作,继续执行主程序逻辑,下面是该库作者提供的原理图:

这种方法有效地模拟了fork的行为,同时避免了Go运行时中与线程和goroutine相关的问题。下面是使用go-daemon包实现Go守护进程的示例:

// daemonize/go-daemon/main.go

package main

import (
    "log"
    "time"

    "github.com/sevlyar/go-daemon"
)

func main() {
    cntxt := &daemon.Context{
        PidFileName: "example.pid",
        PidFilePerm: 0644,
        LogFileName: "example.log",
        LogFilePerm: 0640,
        WorkDir:     "./",
        Umask:       027,
    }

    d, err := cntxt.Reborn()
    if err != nil {
        log.Fatal("无法运行:", err)
    }
    if d != nil {
        return
    }
    defer cntxt.Release()

    log.Print("守护进程已启动")

    // 守护进程逻辑
    for {
        // ... 执行任务 ...
        time.Sleep(time.Second * 30)
    }
}

运行该程序后,通过ps可以查看到对应的守护进程:

$make
go build -o go-daemon-app
$./go-daemon-app 

$ps -ef|grep go-daemon-app
  501  4025     1   0  9:20下午 ??         0:00.01 ./go-daemon-app

此外,该程序会在当前目录下生成example.pid(用于实现file lock),用于防止意外重复执行同一个go-daemon-app:

$./go-daemon-app
2024/09/26 21:21:28 无法运行:daemon: Resource temporarily unavailable

虽然原生守护进程化提供了精细的控制且无需安装和配置外部依赖,但进程管理工具提供了额外的功能,如开机自启、异常退出后的自动重启和日志记录等,并且Go团队推荐使用进程管理工具来实现Go守护进程。进程管理工具的缺点在于需要额外的配置(比如systemd)或安装设置(比如supervisor)。

4. 小结

在Go中实现守护进程化,虽然因为语言运行时的特性而具有挑战性,但通过社区开发的库和谨慎的实现是可以实现的。随着Go语言的不断发展,我们可能会看到更多对进程管理功能的原生支持。同时,开发者可以根据具体需求,在原生守护进程化、进程管理工具或混合方法之间做出选择。

本文涉及的源码可以在这里下载。


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

为什么Canonical Import Path注释在Go中不再必要

本文永久链接 – https://tonybai.com/2024/10/02/why-canonical-import-paths-no-longer-necessary-in-go

Go语言自推出以来,一直以其简洁和高效的包管理系统著称。在Go 1.11版本之前,Canonical Import Path注释曾是一个重要的工具,用于防止包路径的导入冲突。然而,随着Go Modules的引入,这一工具的作用逐渐被淡化。那么Canonical Import Path注释是否还有必要存在呢?在这篇文章中,我就来介绍一下Canonical Import Path的历史及作用,并通过在Go Modules环境下的向后兼容性测试,讨论是否仍有必要继续使用这一注释。

1. 什么是Canonical Import Path注释?

Go在1.4版本中增加了Canonical Import Path,Canonical Import Path用于解决同一个包可能被通过多个导入路径导入的问题。比如当代码托管在像github.com这样的服务上时,导入路径会包含托管服务的域名,比如“github.com/rsc/pdf。但是Go开发者也可以为同一个包提供一个“自定义”或“vanity”导入路径,例如rsc.io/pdf。这样就会产生两个有效的导入路径,这会带来以下问题:

  • 同一个程序中可能会通过不同路径导入同一个包,造成不必要的重复。
  • 使用非官方路径时可能会错过包更新,因为路径没有得到正确识别。
  • 将包迁移到另一个托管服务时,可能会中断使用旧路径的客户端。

为了解决这个问题,Go 1.4引入了Canonical Import Path注释。在包声明中加上注释后,如果通过非Canonical Import Path导入包,Go命令将拒绝编译导入包的程序。

Canonical Import Path的语法很简单,在包声明的注释部分加上标识。例如,对于rsc.io/pdf包,声明可以写成:

package pdf // import "rsc.io/pdf"

这样,Go命令就会拒绝编译任何通过github.com/rsc/pdf路径导入的包,确保代码可以在不破坏用户代码的前提下自由迁移。

2. Go Modules及其对导入路径的影响

Go 1.11引入Go Modules后,Go通过go.mod文件管理包的依赖关系和版本,极大简化了包的管理过程。通过在go.mod中定义模块的根路径,Go Modules可以自动指示项目中所有包的导入路径,并且是唯一的,这使得Canonical Import Path在Go Modules环境下基本没什么必要性了

例如,假设go.mod文件定义了以下模块路径:

// go.mod
module rsc.io/pdf

那么位于项目根目录下的包的导入路径将被自动解析为rsc.io/pdf,避免了包路径冲突问题。因此,在Go Modules的支持下,手动设置Canonical Import Path注释变得不再必要。

Go提供了Go1向后兼容,在Go module下使用Canonical Import Path注释会是什么情况呢?我们接下来来看看。

3. 在Go Modules下使用Canonical Import Path注释

虽然Go Modules简化了包管理,很多老项目仍然保留了Canonical Import Path注释。为了验证在Go Modules环境下继续使用这些注释的兼容性,我进行了以下测试(测试环境使用的是包括Go 1.23.0版本在内的多个Go版本)。

在这个测试中,我们保持项目中的Canonical Import Path注释不变,看看它是否影响在Go Modules环境中的编译和运行。

这里我们直接使用位于github.com/rsc/pdf中的pdf包,该包在read.go文件中使用了Canonical Import Path注释:

// https://github.com/rsc/pdf/blob/master/read.go
package pdf // import "rsc.io/pdf"

我们先用Go 1.11版本之前的Go版本测试一下导入rsc.io/pdf包。由于Go 1.11版本之前依然采用的是GOPATH构建模式,因此需要先将github.com/rsc/pdf下载到\$GOPATH/src的github.com/rsc下,因为GOPATH模式下,go编译器回到\$GOPATH路径下搜寻依赖包。

接下来,我们建立demo1目录,并直接将github.com/rsc/pdf/pdfpasswd/main.go复制到demo1目录下,该main.go导入了”rsc.io/pdf”,我们将其改为导入”github.com/rsc/pdf”:

// demo1/main.go

package main

import (
    "flag"
    "fmt"
    "log"
    "os"

    "github.com/rsc/pdf"
)

var (
    alphabet  = flag.String("a", "0123456789", "alphabet")
    maxLength = flag.Int("m", 4, "max length")
)

func usage() {
    fmt.Fprintf(os.Stderr, "usage: pdfpasswd [-a alphabet] [-m maxlength] file\n")
    os.Exit(2)
}

func main() {
    log.SetFlags(0)
    log.SetPrefix("pdfpasswd: ")

    flag.Usage = usage
    flag.Parse()
    if flag.NArg() != 1 {
        usage()
    }

    f, err := os.Open(flag.Arg(0))
    if err != nil {
        log.Fatal(err)
    }

    last := ""
    alpha := *alphabet
    ctr := make([]int, *maxLength)
    pw := func() string {
        inc(ctr, len(alpha)+1)
        for !valid(ctr) {
            inc(ctr, len(alpha)+1)
        }
        if done(ctr) {
            return ""
        }
        buf := make([]byte, len(ctr))
        var i int
        for i = 0; i < len(buf); i++ {
            if ctr[i] == 0 {
                break
            }
            buf[i] = alpha[ctr[i]-1]
        }
        last = string(buf[:i])
        println(last)
        return last
    }
    st, err := f.Stat()
    if err != nil {
        log.Fatal(err)
    }
    _, err = pdf.NewReaderEncrypted(f, st.Size(), pw)
    if err != nil {
        if err == pdf.ErrInvalidPassword {
            log.Fatal("password not found")
        }
        log.Fatal("reading pdf: %v", err)
    }
    fmt.Printf("password: %q\n", last)
}

func inc(ctr []int, n int) {
    for i := 0; i < len(ctr); i++ {
        ctr[i]++
        if ctr[i] < n {
            break
        }
        ctr[i] = 0
    }
}

func done(ctr []int) bool {
    for _, x := range ctr {
        if x != 0 {
            return false
        }
    }
    return true
}

func valid(ctr []int) bool {
    i := len(ctr)
    for i > 0 && ctr[i-1] == 0 {
        i--
    }
    for i--; i >= 0; i-- {
        if ctr[i] == 0 {
            return false
        }
    }
    return true
}

然后,我们先用Go 1.10.8版本编译该main.go,得到下面结果:

$go run main.go
main.go:9:2: code in directory /Users/tonybai/Go/src/github.com/rsc/pdf expects import "rsc.io/pdf"

我们看到go 1.11之前的版本对pdf包声明的Canonical Import Path做了检查,如果实际导入路径(github.com/rsc/pdf)与其不符,Go编译器会报错!

接下来,我们来看看切换到go module模式后的编译结果,这里我们使用Go 1.12.7版本。我们创建go.mod文件:

// demo1/go.mod
module demo1

go 1.12

编译执行main.go:

$go run main.go
go: finding github.com/rsc/pdf v0.1.1
go: downloading github.com/rsc/pdf v0.1.1
go: extracting github.com/rsc/pdf v0.1.1
usage: pdfpasswd [-a alphabet] [-m maxlength] file
exit status 2

我们看到,go 1.12.7可以成功编译并运行main.go,即便后者没有使用Canonical Import Path导入pdf包。

而用最新的Go 1.23.0编译和运行,也是没问题的:

$go run main.go
usage: pdfpasswd [-a alphabet] [-m maxlength] file
exit status 2

由此可以得出结论:go module模式下,Go编译器已经不再校验导入包的Canonical Import Path了。

并且,即便main.go同时导入rsc.io/pdf和github.com/rsc/pdf也是没问题的:

import (
    "flag"
    "fmt"
    "log"
    "os"

    "github.com/rsc/pdf"
    _ "rsc.io/pdf"
)

这是因为github.com/rsc/pdf下没有go.mod,go编译器无法识别github.com/rsc/pdf和rsc.io/pdf是同一个包。我们再看一个uber-go/zap的例子:

package main

import (
    "fmt"

    _ "github.com/uber-go/zap"
    _ "go.uber.org/zap"
)

func main() {
    fmt.Println("hello, zap!")
}

针对这个main.go所在的go module进行go mod tidy,我们会得到如下错误结果:

$go mod tidy
go: finding module for package go.uber.org/zap
go: finding module for package github.com/uber-go/zap
go: downloading go.uber.org/zap v1.27.0
go: downloading github.com/uber-go/zap v1.27.0
go: found github.com/uber-go/zap in github.com/uber-go/zap v1.27.0
go: found go.uber.org/zap in go.uber.org/zap v1.27.0
go: demo imports
    github.com/uber-go/zap: github.com/uber-go/zap@v1.27.0: parsing go.mod:
    module declares its path as: go.uber.org/zap
            but was required as: github.com/uber-go/zap

我们看到:go命令检测出了github.com/uber-go/zap仓库下的go module是go.uber.org/zap,我们只能使用go.uber.org/zap作为zap包的导入路径。

4. 是否应移除Canonical Import Path注释?

在Go Modules已经成为Go项目默认包管理方式的背景下,Canonical Import Path的使用显得冗余。虽然保留这些注释不会导致兼容性问题,但移除它们可以让项目代码更加简洁,减少不必要的历史包袱。

对于已经迁移到Go Modules的老项目,开发者可以考虑逐步移除Canonical Import Path注释。对于新项目,则是没有必要添加Canonical Import Path注释,Go Modules已经足够强大,能够管理包路径和依赖;如果项目的用户仍依赖旧版Go工具链(GOPATH模式),保留Canonical Import Path注释则可以作为一种保险措施。

5. 小结

Canonical Import Path注释在Go 1.4引入时是为了解决包路径冲突和包迁移问题。然而,随着Go Modules的引入,包管理和路径控制功能逐渐被自动化,Canonical Import Path的作用显得不再必要。对于现代Go项目,开发者应考虑移除这一冗余的注释,这不仅是代码简化的一部分,也反映了Go生态系统中包管理方式的演进,并使项目更加符合Go语言的现代开发环境。


Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时,我们也会加强代码质量和最佳实践的分享,包括如何编写简洁、可读、可测试的Go代码。此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats