1
username@yosemite ~ % ps wwwaux | grep java
username        48111   0.0  0.0        0      0   ??  ?E   11:54AM   0:00.00 (java)
username        91673   0.0  0.0  2432772    508 s006  R+    3:19PM   0:00.00 grep java
username        90809   0.0  0.0        0      0   ??  ?E   12:47PM   0:00.00 (java)

Every so often I will get a JVM hung like this. What do the (java) process listings mean? How do I kill them? kill -9 48111 does nothing, and AFAICT the listings stay there until I reboot.

javanix
  • 247
  • 3
  • 15

1 Answers1

1

When in doubt refer to the man page :)

$ man ps
/parenth

When printing using the command keyword, a process that has exited and
has a parent that has not yet waited for the process (in other words,
a zombie) is listed as ``<defunct>'', and a process which is blocked
while trying to exit is listed as ``<exiting>''.  If the arguments
cannot be located (usually because it has not been set, as is the case
of system processes and/or kernel threads) the command name is printed
within square brackets.  The process can change the arguments shown
with setproctitle(3).  Otherwise, ps makes an educated guess as to the
file name and arguments given when the process was created by
examining memory or the swap area.  The method is inherently somewhat
unreliable and in any event a process is entitled to destroy this
information.  The ucomm (accounting) keyword can, however, be depended
on. If the arguments are unavailable or do not agree with the ucomm
keyword, the value for the ucomm keyword is appended to the arguments
in parentheses.

Additionally:

KEYWORDS
  The following is a complete list of the available keywords and their meanings.
  Several of them have aliases (keywords which are synonyms).
  ...
  ucomm      name to be used for accounting

It would appear those are zombie processes, and instead of just returning <defunct> as the process name it's returning what was stored in some kind of accounting record.

As for killing these processes, rebooting may be the best option. Since they lost their original PPID and become children of PPID 1 (launchd). You can try sending a HUP signal to launchd, but don't try to send a SIGKILL or SIGTERM signal to it, or you'll crash your system.

You can verify the PPID of the zombie processes using ps -ef.

Note: having a few zombie processes shouldn't hurt anything. The process isn't actually running anymore, it has been terminated and isn't using any system resources, other than an entry in the process table.

Gene
  • 3,633
  • 19
  • 39
  • Yeah, the problem is these processes are holding onto some ports, (or at least Eclipse thinks so), so I can't restart my Tomcat instances without either changing the ports or rebooting, either of which are a pain when trying to develop. – javanix Aug 10 '15 at 21:51
  • That's strange. Can you verify if the ports are actually in use, for example: `sudo lsof -P -n -i:###`. Replace `###` with the port number. – Gene Aug 10 '15 at 21:53
  • They are not actually in use, per `lsof` as you mentioned. The only trace on the system that I can find of them is the "zombie-like" processes. This may be YASEE (Yet Another Stupid Eclipse Error) but not being able to remove those entries from the process table without a reboot smells deeper than that. – javanix Aug 10 '15 at 21:59
  • I wonder if eclipse keeps track of the PIDs, or if there's some kind of temporary PID file it's referring to that gets cleaned up on reboot. I imagine you've tried restarting eclipse? You can try sending HUP to PID 1 to see if it gets rid of those processes, just make sure you've saved all of your work before continuing. – Gene Aug 10 '15 at 22:01
  • For the record this is what Eclipse claims is the issue - `Several ports (52358, 62327) required by Tomcat v7.0 Server at localhost (sshd) are already in use. The server may already be running in another process, or a system process may be using the port. To start this server you will need to stop the other process or change the port number(s).` – javanix Aug 10 '15 at 22:01
  • that's a good point - I'll dig through the server config directory. Still irritating that there's apparently no way of excising those processes from the process table on OS X. – javanix Aug 11 '15 at 14:57
  • launchd will try to clear them up, but there's something preventing it from doing that. Did you try the HUP? – Gene Aug 11 '15 at 15:36