doushaqing7080 2019-04-22 16:44
浏览 427

golang中server.GracefulStop()的行为

I have a gRPC server, and I have implemented graceful shutdown of my gRPC server something like this

fun main() {
    //Some code
    term := make(chan os.Signal)
    go func() {
            if err := grpcServer.Serve(lis); err != nil {
                term <- syscall.SIGINT
            }
        }()

    signal.Notify(term, syscall.SIGTERM, syscall.SIGINT)
    <-term
    server.GracefulStop()
    closeDbConnections()
}

This works fine. If instead I write the grpcServer.Serve() logic in main goroutine and instead put the shutdown handler logic into another goroutine, statements after server.GracefulStop() usually do not execute. Some DbConnections are closed, if closeDbConnections() is executed at all.

server.GracefulStop() is a blocking call. Definitely grpcServer.Serve() finishes before server.GracefulStop() completes. So, how long does main goroutine take to stop after this call returns?

The problematic code

func main() {
    term := make(chan os.Signal)
    go func() {
        signal.Notify(term, syscall.SIGTERM, syscall.SIGINT)
        <-term
        server.GracefulStop()
        closeDbConnections()
    }()
    if err := grpcServer.Serve(lis); err != nil {
        term <- syscall.SIGINT
    }
}

This case does not work as expected. After server.GracefulStop() is done, closeDbConnections() may or may not run (usually does not run to completion). I was testing the later case by sending SIGINT by hitting Ctrl-C from my terminal.

Can someone please explain this behavior?

  • 写回答

1条回答 默认 最新

  • duanji9311 2019-04-22 20:27
    关注

    I'm not sure about your question (please clarify it), but I would suggest you to refactor your main in this way:

    func main() {
    
       // ...
    
       errChan := make(chan error)
       stopChan := make(chan os.Signal)
    
       // bind OS events to the signal channel
       signal.Notify(stopChan, syscall.SIGTERM, syscall.SIGINT)
    
       // run blocking call in a separate goroutine, report errors via channel
       go func() {
            if err := grpcServer.Serve(lis); err != nil {
                errChan <- err
            }
        }()
    
       // terminate your environment gracefully before leaving main function
       defer func() {
          server.GracefulStop()
          closeDbConnections()
       }()
    
       // block until either OS signal, or server fatal error
       select {
          case err := <-errChan:
              log.Printf("Fatal error: %v
    ", err) 
          case <-stopChan:
       }
    

    I don't think it's a good idea to mix system events and server errors, like you do in your example: in case if Serve fails, you just ignore the error and emit system event, which actually didn't happen. Try another approach when there are two transports (channels) for two different kind of event that cause process termination.

    评论

报告相同问题?

悬赏问题

  • ¥15 seatunnel-web使用SQL组件时候后台报错,无法找到表格
  • ¥15 fpga自动售货机数码管(相关搜索:数字时钟)
  • ¥15 用前端向数据库插入数据,通过debug发现数据能走到后端,但是放行之后就会提示错误
  • ¥30 3天&7天&&15天&销量如何统计同一行
  • ¥30 帮我写一段可以读取LD2450数据并计算距离的Arduino代码
  • ¥15 C#调用python代码(python带有库)
  • ¥15 飞机曲面部件如机翼,壁板等具体的孔位模型
  • ¥15 vs2019中数据导出问题
  • ¥20 云服务Linux系统TCP-MSS值修改?
  • ¥20 关于#单片机#的问题:项目:使用模拟iic与ov2640通讯环境:F407问题:读取的ID号总是0xff,自己调了调发现在读从机数据时,SDA线上并未有信号变化(语言-c语言)