今天用 superverisor 管理一个 使用了beego 库的 程序出现了一些坑,不用superverisor 管理时正常运行,用了之后进程无法启动。首先声明一下,这个程序不是完全使用beego 框架 ,只是使用了里面的库"github.com/astaxie/beego" beego.Run()
先看看superverisor 报啥错
因为程序会自动执行beego 包的init 函数,其中执行到config 包的init 函数时出现了问题,先看代码
beego/config.go
func init() {
BConfig = newBConfig()
var err error
if AppPath, err = filepath.Abs(filepath.Dir(os.Args[0])); err != nil {
panic(err)
}
workPath, err := os.Getwd()
if err != nil {
//panic(err) //supverisor 管理时无法获取 getwd
workPath = "/tmp"
}
appConfigPath = filepath.Join(workPath, "conf", "app.conf")
if !utils.FileExists(appConfigPath) {
appConfigPath = filepath.Join(AppPath, "conf", "app.conf")
if !utils.FileExists(appConfigPath) {
AppConfig = &beegoAppConfig{innerConfig: config.NewFakeConfig()}
return
}
}
if err = parseConfig(appConfigPath); err != nil {
panic(err)
}
}
其实我这个程序本来就不需要beego 自带的配置文件, 但是由于引用了包,所以还是执行了,
但是在 os.Getwd() 这里时返回了err 导致panic ,按道理不应该,我直接运行这个程序没问题,加入到superverisor 管理时就出现了问题,估计是在superverisor 里面运行时无法正确调用 os.Getwd() ,没办法改了一下beego 的源码 去掉panic 随便弄了个workPath = "/tmp" 因为我本来就没打算用beego 框架的配置文件 只需要返回一个 AppConfig 对象我自己上层应用赋值就行了,下面看看 os.Getwd() 里面到底是啥,
func Getwd() (dir string, err error) {
if runtime.GOOS == "windows" {
return syscall.Getwd()
}
// Clumsy but widespread kludge:
// if $PWD is set and matches ".", use it.
dot, err := Stat(".")
if err != nil {
return "", err
}
dir = Getenv("PWD")
if len(dir) > 0 && dir[0] == '/' {
d, err := Stat(dir)
if err == nil && SameFile(dot, d) {
return dir, nil
}
}
// If the operating system provides a Getwd call, use it.
// Otherwise, we're trying to find our way back to ".".
if syscall.ImplementsGetwd {
s, e := syscall.Getwd()
if useSyscallwd(e) {
return s, NewSyscallError("getwd", e) //此时返回了err
}
}
.........
在syscall.Getwd() 里面返回了err ,再看看这个函数
var useSyscallwd = func(error) bool { return true }
我的天,这里返回的就是true ,搞不懂这个系统包为什么这样做,难道是go 的一个bug,其实我觉得应该是beego 的一个bug 没有考虑到用supervisor 这些管理工具 导致有些系统函数无法正常返回