Yes, this is the same behavior I observe (except I can't figure out how to close an SSH session while leaving the octave process running on the remote).

The reason for zombie processes is that the gnuplot process has exited (probably because gnuplot detected that your DISPLAY disconnected) but Octave is still running and has not cleaned up the child process resources that it spawned. I can achieve the same result in a desktop session by simply plotting a gnuplot figure and then killing the gnuplot process outside of Octave. But once Octave is killed, the zombies are taken care of by the system. This is standard expected Unix behavior.

So I think this is only partly a bug in Octave, but the main issue you're having is that the connection is closed, killing gnuplot but not killing Octave. You should either arrange for your users to "close all" before exiting, or to actually exit Octave before closing putty, figure out how to make putty close the SSH session properly, or have a cleanup process on the server that takes care of leftover Octave processes that users have left behind after logging off. Having leftover unused running Octave sessions seems more wasteful and serious to me than defunct gnuplot processes. Fix that problem with your workflow and you won't have zombie processes on your system.

There is already another bug about Octave creating zombie processes in a different way, so I'll close this bug as a duplicate of bug #37591. The eventual fix for that bug may mean no more gnuplot processes left over, but that's not the real problem with your setup.

Yes, octave is still running actually:

ps aux | grep octave
191:user      3674  0.0  0.5 240380 42104 ?        S    Jun24   0:09 /usr/local/bin/octave-cli-3.8.0
202:user     12074  0.0  0.4 235984 37060 ?        S    Jun26   0:03 /usr/local/bin/octave-cli-3.8.0
206:user     24623  0.0  0.4 231440 33180 ?        S    Jul07   0:00 /usr/local/bin/octave-cli-3.8.0

Note the similarity with these pids vs the ones mentioned before.

Perhaps this is an issue with how PuTTY closes an SSH session?

"Thanks for your bug report. For clarity, is the bug that gnuplot figures are "crashing" (disappearing?), or that Octave is crashing, or that zombie processes are being left behind on your server when the clients are done with their Octave session?"

My apologies: Zombie processes are being left behind on my server when the clients are done with their Octave session.



"What do you mean by an "Octave server"? Is each client running its own instance of Octave over an SSH session? If so, then when Octave exits the gnuplot processes should be cleaned up."

Yes, each client is running octave over SSH through PuTTY, using X11 forwarding to xming.


"Or do you mean each client is somehow connecting to a single instance of Octave that stays running in the background? "

No, each SSH instance starts its own Octave session.



Recreating the issue:
Start xming
ssh to the server, with X11 forwarding, from PuTTY
Create a plot using gnuplot:

figure
x=0:.01:2*pi
y=sin(x)
plot(x,y)

Check processes on server:
  ps aux | grep gnuplot
  253:user     24624  0.0  0.1 191732 12536 pts/19   S+   22:43   0:00 gnuplot
  254:user     24626  0.0  0.0  27560  1632 pts/19   S+   22:43   0:00 gnuplot_x11
Close PuTTY by clicking on the X in windows

Check processes on server:
  ps aux | grep gnuplot
  250:user     24624  0.0  0.0      0     0 ?        Z    22:43   0:00 [gnuplot] <defunct>



Looking at this log, it seems that two instances are being created, gnuplot and gnuplot_x11. The latter gets terminated. The former gets abandoned.

The setup that I am using is unique. Several Windows clients use xming and putty to run from an octave server.

I am not sure the method that is being used to exit the putty / xming setup, or how gracefully it is being closed, but gnuplot processes are left defunct on the host machine.

I am running 3.8.1, possibly with a single bug fix from the waitbar function compiled in. Gentoo OS.

I am not sure if this is an issue with gnuplot, octave, putty, xming, etc. so it might not be relevant but I though I'd log it somewhere.


ps aux | grep gnuplot
203:user      3919  0.0  0.0      0     0 ?        Z    Jun24   0:00 [gnuplot] <defunct>
206:user     12092  0.0  0.0      0     0 ?        Z    Jun26   0:00 [gnuplot] <defunct>