in Fun

Dynamic Registration In 12c Using LREG….

There is a lot of change that release 12.1 or 12c has brought up. And it’s not in the more advanced new features that I am talking about but even in some areas about which, we have memorized a particular concept by heart from last many years. Once such change is what I am going to mention in this post-introduction of the LREG(Listener Registration) process.

Basics of Dynamic Registration
In the earlier releases,to register an instance with the listener, dba’s were required to manage the lsitener configuration file-Listener.ora. One would need to mention in this file the specifications of database whose instance we would want listener to listen for incoming connection requests. Not that it was very hard to do but it was still one of those tasks which if could be made automatic, it would make life a little simpler. And that’s what happened when from 9i onwards. The requirement to use a listener.ora file to  register an instance with the listener was removed from this release and this task was delegated to the PMON(Process Monitor) process. At the time of the instance startup, PMON process would register the instance with the listener. If the listener is not up, it would keep on looking for the listener and once it’s up, the registration would happen with a delay of about 60 seconds. And this continued till 11.2.

Now, from 12.1, the same is handled by a process dedicated for this work, LREG(Listener Registration)process.

If I had stopped here, it would be a very simple post and probably, a not-so-interesting one either. So I thought to explain a little more. If you are interested to understand how does the whole thing works, keep on reading it.

How does Dynamic Registration works?

There is a lot that goes on behind the scene when the database and its related processes are functional. And all of it goes back to how OS works. In the dynamic registration, two important concepts-File Descriptors and Sockets come into the play.

When the listener process starts, it creates two socket files under the location /var/tmp/.oracle. I haven’t started my listener right now. So let’s see what’s the output from the folder,


There is no Listener process running but there is a [netns] process owned by Root. It stands for Network Namespace process of Linux and is spawned by the [ktthreadd] (Kernel Thread Daemon), used to spawn other kernel threads. There is nothing required to be done about [netns] by a DBA.

If the listener process is started(the output is from a previous session when I started the listener), you can see the socket files created by the listener process in my version running on OEL 6.5 below,



As I said, there are several file descriptors that are created and all of them are present under the /proc file system. Below are the file descriptors that I had got in my system,


Since we know that our listener’s PID was 3022, let’s check that out by going into the folder with the same PID.



You can see two folders, FD and FDINFO. Let’s see what we have inside the folder  FD.


And we can see that there are several file descriptors that are there.

Thus it is established that there are file descriptors and sockets that get created for the process and in our case, we have checked the same for our listener process.

So how does these two get fit into the dynamic registration done by LREG process (and in the previous release, PMON)? Well, it’s simple. The processes use system calls to see that whether the listener is up or not(listener doesn’t need to be there for the database to be started). If there is no listener process found, the wait continues and after a certain time(3000 milliseconds) , a retry is done. This keeps on going till the listener is started and when that happens, the file descriptor opened by the listener is “binded” by the process to estabilish the connection between each other.

To find what the LREG process is doing, I used STRACE os utility to trace it’s working. The output for the PMON process in 11203 wasn’t entirely the same but I guess, that’s expected as it wasn’t a process dedicated for just getting the instance registered with the listener. On the other hand, LREG’s sole purpose is the dynamic registratior so that might explain the little difference between the system calls used between the two processes.

To see what happens when the listener is not present, I just started the database and used strace over it. Below is the excerpt of the output of STRACE,


We can see few system calls here , starting with epoll_wait that is used to represent the time waiting for events over file descriptors.The last argument is showing the time in milliseconds-3000 milliseconds(which means 3 seconds) . Skipping the next two lines for the resource usage consumption, the times function returning the time in seconds and if you notice, it’s having a difference of 3 between the above posted two snippets of the output.

Next snippet is going to be a little bigger and that’s where the entire action is happening.

Picking up the relevant thing from the output, the first interesting piece is the starting itself,


What is happening is that a socket function is used to work with file descriptor 17. I guess this is a fixed sort of file descriptor that’s used in establishing the connection with the listener process. The socket used here is NETLINK which is used to create a connection between the kernel and the network layers.

Moving on, the next line is


Here a bind attempt with the file descriptor 17, returned from the previous statement is initiated. In the next few lines, this file descriptor would be used to initiate the connection with the PID 2581, which is the the PIF of LREG process.


Now, the details of the host IP address is gathered using the file  /etc/hosts.


An attempt to estabilish the connect with IP address is in progress.


Since there is no listener process started yet and also, there is no file descriptor 17 associated with the process LREG yet, the connection is refused. There is no established connection on the as well and we can confirm it using the LSOF command.


Also, there is no such file-descriptor in the /proc for PID 2581 as well.


Now, let’s start the listener. I had kept the tracing going on when the listener was started. The very first thing to notice is that in the /proc file-system, the file-descriptor 17 is now available.


In the strace, there isn’t any change in the output and the same system calls that we have seen in the previous output are used except that now,there won’t be any connection refused message.

We can now see that the connection is estabilished using the same LSOF command,


We can see that file descriptor 17u(u stands for the mode, read and write) is used by the LREG process to estabilish a TCP connection. Also the socket files are created under the /var/tmp/.oracle folder for the listener process 7902.


In case you are wondering what is this ncube-lm thingy shown in the output, that’s
NCube-License Manager. If you check out the website,, it seems that this port is assigned to Maxine Yuen. So seems like the port 1521 is not really owned but just used or shared by Oracle Corp for the listener process. Interesting isn’t it?

Before ending the post, if you are not willing to use Strace, you can opt for listener tracing as well. I haven’t posted the output of that here though.

Hope it helps, in some way!