Until last week I din’t know about a listener process having one or more childrens (a child process has exactly the same name as its parent but have their parent-pid set to the parent listener pid). Trying to find information about the existence of listener child processes (first of all I wanted to know if this is “normal”) always pointed to some bug that was there until 10.2.0.3 about a hanging listener process in combination with a listener having a child process.
It appears that these children processes only show up on servers that are heavy loaded. In normal situations you don’t see these child processes because they are only there for a split second (so they are “normal” but they are to quick to see!).
This is the explanation for listener child processes being there:
- Listener (parent) listens on a configured port number (default 1521)
- When it receives a request, accepts it
- The listener (parent) process forks itself (creating a child process) both using the same socket.
- The listener (parent) process detaches from the socket and will start listening on the configured listener port number again, waiting for new connection requests.
- The “child” listener closes all unnecessary parent listener resources (various file descriptors) and will start the Oracle binary (overwriting itself) which will let the Oracle binary inherit existing resources (like stdin, stdout en stderr) and socket to let Oracle communicate with the client.
This means that when you see listener child processes this means, the child listener process wasn’t overwritten by the Oracle binary just yet. When you have a server under heavy load, this overlaying could take longer than normal thus you seeing child listeners.