Hello!
I'd like to ask for some help regarding a zombie (or something similar to a zombie) process. I have a process stuck in the T state, so it's terminated. It produced an error by reading malformed input data, but instead of handling it properly, it just got stuck somehow. It's parent is already dead, and another process that was feeding this one with data via a pipe is also dead. The malformed input file it had been reading from the disk is already gone, as I deleted it. I cannot attach to the process via truss either. If I try, truss just sits there doing nothing.
I wouldn't care too much about that, I can probably reboot in a month or two. But here's the thing: This process is growing in size, so RES is increasing steadily, 1MiB every 20-30 seconds or so. It appears to be leaking?
Since I cannot kill it even with signal 9 / sigkill, I'm getting scared of it. Can the OOM killer murder it, if it gets too large? I guess not, right? My fear is, that this process will endanger other long-running processes as soon as available memory becomes scarce. I can just hot-add more swap, but... uh... I'm not sure if that's so smart in the long run.
It shouldn't be an I/O problem, as the underlying disk ist local and works perfectly fine. No other processes had issues with it during the same time.
Is there anything I can do to at least stop it from eating up my memory?
Thanks!
Edit: I guess I should probably provide more information... But I'm not sure what exactly. The system I'm using is FreeBSD 12.1-RELEASE-p2 running the GENERIC kernel on x86_64. The problematic process is x265 3.3+1 (release version, compiled with clang 8.0.1). It was running within tmux being fed data by ffmpeg. The "malformed input data" was actually an encoding pass 1 statistics file x265 itself had written beforehand. The problem ocurred in encoding pass 2, where it is supposed to use the pass 1 statistics file for optimization. Those details probably won't help much though.
I'd like to ask for some help regarding a zombie (or something similar to a zombie) process. I have a process stuck in the T state, so it's terminated. It produced an error by reading malformed input data, but instead of handling it properly, it just got stuck somehow. It's parent is already dead, and another process that was feeding this one with data via a pipe is also dead. The malformed input file it had been reading from the disk is already gone, as I deleted it. I cannot attach to the process via truss either. If I try, truss just sits there doing nothing.
I wouldn't care too much about that, I can probably reboot in a month or two. But here's the thing: This process is growing in size, so RES is increasing steadily, 1MiB every 20-30 seconds or so. It appears to be leaking?
Since I cannot kill it even with signal 9 / sigkill, I'm getting scared of it. Can the OOM killer murder it, if it gets too large? I guess not, right? My fear is, that this process will endanger other long-running processes as soon as available memory becomes scarce. I can just hot-add more swap, but... uh... I'm not sure if that's so smart in the long run.
It shouldn't be an I/O problem, as the underlying disk ist local and works perfectly fine. No other processes had issues with it during the same time.
Is there anything I can do to at least stop it from eating up my memory?
Thanks!
Edit: I guess I should probably provide more information... But I'm not sure what exactly. The system I'm using is FreeBSD 12.1-RELEASE-p2 running the GENERIC kernel on x86_64. The problematic process is x265 3.3+1 (release version, compiled with clang 8.0.1). It was running within tmux being fed data by ffmpeg. The "malformed input data" was actually an encoding pass 1 statistics file x265 itself had written beforehand. The problem ocurred in encoding pass 2, where it is supposed to use the pass 1 statistics file for optimization. Those details probably won't help much though.