Java进程运行1小时自动终止的问题调试步骤咨询

我之前也碰到过类似的SSM会话超时问题，结合你的场景，给你整理几个逐步排查的方向：

• 先查SSM本身的超时配置
  SSM Run Command和Session Manager默认有会话超时限制，大概率是这个在搞鬼。你可以先去AWS控制台的SSM服务里，查看Run Command的执行历史，找到对应任务的终止原因描述——如果是超时，那就能直接定位。另外，检查你用来触发脚本的SSM文档，看看里面的timeoutSeconds参数是不是设成了3600（刚好1小时），如果是，调大这个值试试。
  还有，SSM代理的配置文件/etc/amazon/ssm/amazon-ssm-agent.json里也有SessionTimeout这类设置，也可以核对一下。

• 深挖日志细节
  首先看Java服务的日志：你的nohup命令没指定输出文件，默认会写到/path/to/jar/directory/nohup.out里，去这个文件里找1小时左右的记录，有没有异常堆栈、OOM（内存溢出）或者外部连接断开的信息——毕竟直接运行没问题，但SSM环境下可能有不一样的资源限制。
  然后看SSM代理的日志，路径一般是/var/log/amazon/ssm/amazon-ssm-agent.log和/var/log/amazon/ssm/errors.log，定位到服务终止的时间点，看看是不是代理主动把Java进程杀了。

• 确保nohup真正脱离会话运行
  你当前的subprocess.Popen调用里，没有处理标准输入输出的重定向，也没设置进程组。SSM会话结束时，可能会连带关闭所有关联子进程的IO流，导致Java进程退出。可以修改脚本参数试试：

  p = subprocess.Popen(
      ['nohup', 'java', '-jar', 'SetProcessor.jar', set_id],
      cwd='/path/to/jar/directory',
      stdout=open('/path/to/custom-nohup.out', 'w'),
      stderr=subprocess.STDOUT,
      stdin=subprocess.DEVNULL,
      start_new_session=True
  )
  

  添加start_new_session=True能让Java进程脱离SSM的进程组，避免被会话结束时连带杀死；重定向IO也能防止因为流关闭导致的进程退出。

• 检查系统级别的进程限制
  看看EC2实例上针对SSM运行用户（一般是ssm-user）有没有进程超时或资源限制。先找到Java进程ID（ps aux | grep java），然后用cat /proc/<你的进程ID>/limits查看该进程的资源限制，重点看CPU time、Max processes这些参数有没有被设成1小时的限制。另外，也可以检查下cron定时任务，有没有脚本在定期清理运行超过1小时的进程。

• 做隔离测试
  先手动在EC2实例上运行你的Python脚本，然后退出SSH会话，看看Java服务能不能一直运行——如果能，那问题肯定出在SSM的会话关联上；如果还是会终止，那就要排查脚本本身或者系统层面的问题了。另外，也可以试试用nohup python your_script.py &手动模拟SSM的后台执行场景，观察进程存活情况。

• 排除EC2实例健康问题
  这个概率比较低，但也可以顺带看看EC2控制台的实例状态历史，有没有在服务终止的时间点出现过状态变化（比如重启），排除实例健康检查触发的异常。

内容的提问来源于stack exchange，提问作者Prakhar Mishra