pm2 守护进程在几个小时后死亡 [英] pm2 Daemon Dies After a Few Hours

查看:248
本文介绍了pm2 守护进程在几个小时后死亡的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 Node.js/Express 应用程序,它实现了一组 REST API,我正在尝试使用 pm2 来管理它的部署.该应用程序启动良好(使用 pm2 start生态系统.config.js)并保持可用几个小时,但 pm2 守护进程最终总是死掉,日志中没有任何错误.

I have a Node.js/Express app that implements a set of REST APIs and I'm attempting to use pm2 to manage its deployment. The app starts fine (using pm2 start ecosystem.config.js) and remains available for a few hours, but the pm2 daemon always dies eventually without any errors in the logs.

一些注意事项:

  • 我在 CentOS 7 共享托管环境中运行.
  • /var/log 目录为空,journalctl 不返回任何条目.
  • 我已经确认系统没有重新启动.
  • 我安装的唯一 pm2 模块是 pm2-logrotate.
  • 我正在捕获和记录 SIGINTSIGTERMSIGQUITSIGABRT 信号,但该逻辑似乎永远不会被击中(如果我运行 pm2 stop 就会被击中).
  • 如果我运行 pm2 list,它只会重新启动守护进程并显示一个空的应用程序列表.
  • I'm running in a CentOS 7 shared hosting environment.
  • The /var/log directory is empty and journalctl doesn't return any entries.
  • I've verified that the system isn't rebooting.
  • The only pm2 module I have installed is pm2-logrotate.
  • I'm trapping and logging SIGINT, SIGTERM, SIGQUIT, and SIGABRT signals, but that logic never seems to get hit (it does if I run pm2 stop).
  • If I run pm2 list it just restarts the daemon and shows an empty app list.

这是我的ecosystem.config.js:

module.exports = {
  apps: [
    {
      kill_timeout: 60000,
      listen_timeout: 10000,
      log: 'logs/my-app.log',
      name: 'my-app',
      script: 'dist/index.js',
      wait_ready: true,

      instances: 1,
      autorestart: true,
      watch: false,
      max_memory_restart: '1G',
      env: {
        NODE_ENV: 'development'
      },
      env_production: {
        NODE_ENV: 'production'
      }
    }
  ]
};

这是pm2.log:

2019-04-24T19:20:24: PM2 log: ===============================================================================
2019-04-24T19:20:24: PM2 log: --- New PM2 Daemon started ----------------------------------------------------
2019-04-24T19:20:24: PM2 log: Time                 : Wed Apr 24 2019 19:20:24 GMT-0700 (Mountain Standard Time)
2019-04-24T19:20:24: PM2 log: PM2 version          : 3.5.0
2019-04-24T19:20:24: PM2 log: Node.js version      : 10.5.0
2019-04-24T19:20:24: PM2 log: Current arch         : x64
2019-04-24T19:20:24: PM2 log: PM2 home             : /home/myuser/.pm2
2019-04-24T19:20:24: PM2 log: PM2 PID file         : /home/myuser/.pm2/pm2.pid
2019-04-24T19:20:24: PM2 log: RPC socket file      : /home/myuser/.pm2/rpc.sock
2019-04-24T19:20:24: PM2 log: BUS socket file      : /home/myuser/.pm2/pub.sock
2019-04-24T19:20:24: PM2 log: Application log path : /home/myuser/.pm2/logs
2019-04-24T19:20:24: PM2 log: Process dump file    : /home/myuser/.pm2/dump.pm2
2019-04-24T19:20:24: PM2 log: Concurrent actions   : 2
2019-04-24T19:20:24: PM2 log: SIGTERM timeout      : 1600
2019-04-24T19:20:24: PM2 log: ===============================================================================
2019-04-24T19:20:24: PM2 log: App [pm2-logrotate:0] starting in -fork mode-
2019-04-24T19:20:24: PM2 log: App [pm2-logrotate:0] online
2019-04-24T19:20:24: PM2 log: App [my-app:1] starting in -fork mode-
2019-04-24T19:20:28: PM2 log: App [my-app:1] online

这是pm2-logrotate-out.log:

"/home/myuser/.pm2/logs/my-app-out-1__2019-04-25_00-00-00.log" has been created
"/home/myuser/my-app/logs/my-app-1__2019-04-25_00-00-00.log" has been created

知道是什么导致了这个问题或者我如何进一步调试它吗?

Any idea what's causing this issue or how I can debug it further?

推荐答案

事实证明这是由于我的托管服务提供商强加的资源限制造成的.我仍然不明白为什么没有记录任何内容来表明发生了什么,但我将其标记为已回答,因为我找到了根本原因.

It turns out that this was caused by resource limiting imposed by my hosting provider. I'm still confused about why nothing was logged to indicate what happened, but I'm marking this as answered since I've found the root cause.

这篇关于pm2 守护进程在几个小时后死亡的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆