我正在pdftoppm将用户提供的 PDF 转换为 300DPI 图像。这很好用，除非用户提供页面非常大的 PDF。 pdftoppm将分配足够的内存来在内存中保存该大小的 300DPI 图像，对于 100 英寸的方形页面，它是 100*300 * 100*300 * 4 字节/像素 = 3.5GB。恶意用户可以给我一个愚蠢的大 PDF 并导致各种问题。
所以我想做的是对我即将运行的子进程的内存使用设置某种硬限制——如果它试图分配超过 500MB 的内存，就让进程死掉。那可能吗？
我不认为 ulimit 可以用于此，但是否有一个等价的进程？
我认为这不是一个不常见的问题：一个进程分配了大量内存（可能是由于内存泄漏错误，因为您尝试处理一个不可行的大输入文件，或者其他什么）。RAM 已满，在某些时候 Linux 必须切换到交换。好吧，有时这只是最后的手段：如果我有一个昂贵的计算，我不想在最后我用完 RAM 时丢失数据。
然而，更常见的是（根据我的经验），内存消耗是不受限制的，通过一个流氓，也许是有缺陷的过程。即，我不仅最终将一些不太急需的数据移动到交换，而且操作系统被迫紧急交换数据负载。不幸的是，这不仅严重破坏了违规过程，而且可以使整个系统几乎陷入停顿（在带有 SSD 的机器上它不再那么糟糕了，但是 OTOH 它让我担心是否可以写入千兆字节和千兆字节的垃圾数据长期损害闪存单元）。
直到我发现问题并手动终止进程（实际上花了几分钟才让我自己登录到虚拟终端！），我的一半运行会话处于交换状态，我需要等待一段时间直到系统运行平稳再次。
这个问题有一个强大的解决方案：强制执行硬内存限制。但是在系统范围内执行此操作有时会杀死我仍然需要的进程，并且如果我必须ulimit在启动违规进程之前手动执行...好吧，我经常会忘记，直到为时已晚。
我会更满意的可能解决方案类型：
SIGSTOPped，所以我有时间弄清楚下一步该做什么。有没有办法获得这种行为或类似行为？