我两次注意到我的应用程序出现空间不足的错误，并且两次在尝试通过登录来解决问题php时都收到错误“写入配置时设备上没有剩余空间” 。ssh
我有足够的可用磁盘空间，两次我的应用程序在通过托管公司的网站手动重启服务器后都恢复了运行。显然，这很不方便，但当我有客户时，这是完全不可接受的。
我检查了/var/log/messages所有可能有助于诊断问题的信息。我发现的所有相关信息似乎都是相关的：
rsyslogd[1032]: imjournal: fopen() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.2102.0-5.el8 try https://www.rsyslog.com/e/2013 ]
我确实cron-job每天两次运行这个：find /tmp -atime +1 -delete。我不认为这是导致问题的原因，但我不确定。这是否是清除的好方法/tmp？
我想，作为一种快速修复方法，我可以告诉php服务器每次遇到空间不足错误时都调用一个 bash 脚本来重新启动它。不过，如果不了解到底是什么故障以及原因，这似乎不是一个好主意。
我正在使用AlmaLinux 8.5（与 Centos 非常相似）和Nginx，php-fpm并且我只有一个VPS。如果您认为我应该包含任何相关信息，我将编辑我的问题。
编辑
在我再次遇到错误之前，显示任何命令的结果都是没有意义的。我创建了一个网页来执行命令shell_exec并在屏幕上显示结果。在发生错误时，我应该能够运行命令，因为没有任何内容写入磁盘：
注意：
只有我才拥有的客户端 SSL 证书和登录详细信息，需要以 root 身份运行 php 并访问此页面，因此我并不担心以 root 身份运行 php 或shell_exec使用用户数据调用所带来的安全隐患。
@NikitaKipriyanov 建议尝试保持我的SSH连接打开。如果我还没有以这种方式设置（php 作为管理员的 root），那么当然尝试禁用SSH超时会更有意义。
当我再次遇到此错误并从测试中获得一些结果时，我会提供更新。请随意将您认为我应该执行的命令放入答案中，因为我可能会投赞成票，如果它能让我解决问题，我会接受答案。
编辑-潜在进展
考虑到我确信我的系统实际上没有耗尽磁盘空间，我原本以为问题出在某个进程仍在使用已删除的文件，或者与崩溃的进程相关的错误。有很多文章指出这会导致磁盘空间不足错误，但没有关于诊断这一具体原因的文章。
但是，我注意到我的 inode 数量一夜之间从 3% 增加到了 7%。我确实有意将数据存储在许多小文件中，但这只能解释我的 inode 数量增加了几个。我已crontab自动创建并存储备份。我确实对此进行了监控，因此我会注意到任何异常情况。
我认为问题在于我的php $_SESSION数组创建了太多的临时文件。$_SESSION数组的大小可以线性增加，因此目前存储的数据量始终很小。我没有创建任何数组备份$_SESSION，因此目前我不会注意到这个数据在增加。这对我来说很容易测试和观察，所以这将是下一步。我不想做任何假设，所以我将等待并观察 inode 计数是否接近 100% 导致崩溃，然后再尝试解决问题。
注意：
一旦我确认了问题，我会将这些额外信息移到答案中。