我正在 ssh 进入 AWS EC2 实例并启动我的 API。我希望 API 继续运行并接受请求。
那么，tmux 是做到这一点的好方法吗？或者，还有更好的方法？我的印象是 tmux 和 screen 更适合长时间的任务。不确定它们是否适合无限期地运行 API。
答案1
tmux并且screen用于保持一个或多个 shell 会话处于活动状态，即使您ssh与目标系统的连接由于任何原因而中断，和/或通过单个连接复用多个 shell 会话（将其视为类似于能够打开多个终端窗口，但没有 GUI 界面）。
相信你可以用于tmux运行您的 API 服务，但如果您的 AWS EC2 实例正在使用systemd（正如许多现代 Linux 发行版所做的那样），“正确”的方法可能是编写一个*.service文件来描述启动和停止服务所需的命令，及其要求（即在您的服务成功启动之前还需要运行哪些其他服务）。
然后你可以将服务文件放在/etc/systemd/system/目录中，运行systemctl daemon-reload，然后你就可以使用systemctl start your-API.service和来操作你的服务了systemctl stop your-API.service。就像标准的系统服务一样 - 因为就systemd其而言，它将要是一个系统服务。
通过这种方式，您可以轻松地指定 API 的资源限制，例如限制 API 被滥用时可能造成的危害。如果您想让 API 服务自动启动？systemctl enable your-API.service你就完成了。
您还可以在.service文件中指定您希望 API 服务在自行崩溃或被终止时自动重新启动。如果您使 API 服务定期调用sd_notify(3)，"WATCHDOG=1"您甚至可以systemd在服务似乎挂起时自动重新启动。
还有一些安全优势：systemd 会为其管理的每个服务创建一个“控制组”，并且该控制组由该服务创建的任何子进程继承。因此，即使您的服务“疯狂”并创建了 10000 个子进程（可能是因为互联网上有人试图滥用它），一个简单的systemd stop your-API.service（或者systemd kill your-API.service如果您希望它停止）现在并且不关心对服务进行受控关闭）足以清理所有这些进程：您不必考虑手动查找正确的进程并终止它们的表达式pkill。pgrep
如果您愿意，systemd 也将能够为chroot您提供服务（限制它只能查看特定目录及其子目录）。或者，如果您在专用于该服务的用户帐户上运行该服务（只要可能，这总是一个好的做法），您可以阻止其进程（及其创建的任何子进程）获得完整的系统管理员权限，即使它们root只需在您的服务文件NoNewPrivileges=true中进行设置，就可以通过某种利用来实现。*.service
有关更多信息和示例，请参阅这个问题在这里 Unix&Linux.SE，或者研究系统上的现有*.service文件并参考man systemd.service并man systemd.exec查看各个关键字的含义。