恐慌在其他goroutine不停止儿童过程

时间:2015-12-04 18:39:54

标签: go

如果我退出(出于任何原因)父应用程序,我需要运行一个长时间运行的子进程并将其终止。

以下是代码:

cmd := exec.Command("./long-process")

defer cmd.Process.Kill()

if err != nil {
    log.Fatal(err)
}

var fail io.ReadCloser
fail.Close()

此处的fail会产生明显的

panic: runtime error: invalid memory address or nil pointer dereference

它按预期工作 - 子进程被杀死。

但这发生在goroutine:

cmd := exec.Command("./long-process")

defer cmd.Process.Kill()

if err != nil {
    log.Fatal(err)
}

go func() {
    var fail io.ReadCloser
    fail.Close()
}()

恐慌仍然发生,但似乎没有调用defer并且没有杀死子进程。

有什么方法可以解决这个问题?

更新我需要一个跨平台的解决方案(至少对Linux和FreeBSD而言)

最小例子:

infinite-loop.sh

#!/bin/bash

while true; do
  sleep 1
done

别忘了

chmod +x infinite-loop.sh

test1.go(为简洁而遗漏了错误检查):

package main

import (
    "time"
    "io"
    "os/exec"
    "runtime"
)

func main() {

    cmd := exec.Command("./infinite-loop.sh")

    cmd.Start()

    defer cmd.Process.Kill()

    go func() {
        time.Sleep(100 * time.Millisecond)
        var fail io.ReadCloser
        fail.Close()
    }()

    for {
        runtime.Gosched()
    }
}

让我们跑吧

ps aux | grep infinite-loop.sh | grep -v grep | wc -l; \
go run test1.go; \
ps aux | grep infinite-loop.sh | grep -v grep | wc -l


     0 <--- !!


panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x2130]

goroutine 5 [running]:
main.main.func1()
.../multiline/test1.go:19 +0x30
created by main.main
.../multiline/test1.go:20 +0x9a

goroutine 1 [runnable]:
runtime.Gosched()
/usr/local/Cellar/go/1.5.1/libexec/src/runtime/proc.go:166 +0x14
main.main()
.../multiline/test1.go:23 +0x9f
exit status 2

     1 <--- !!
退出前有<0> 0个进程,退出后有1个进程。

如果您注释掉goroutine代码 - 它可以正常工作。

现在我们可以杀了它:

kill $(ps aux | grep infinite-loop.sh | grep -v grep | awk {'print $2'})

1 个答案:

答案 0 :(得分:2)

没有自动杀死子进程的跨平台解决方案。

在Linux上,您可以使用pdeathsig功能:

cmd := exec.Command("./long-process")

cmd.SysProcAttr = &syscall.SysProcAttr{
    Pdeathsig: syscall.SIGTERM,
}

在其他平台上,孩子需要确定何时自行退出。一种方法是监视从父级给它的管道或插槽FD。如果出现问题,您还可以让某个进程管理器监视进程并进行清理。

总的来说,恐慌应该是罕见的,并得到修复。如果确实存在容易出现恐慌的代码区域,则可以在本地进行恢复,并在退出之前调用子进程的清理。