My troubles with dhcdbd, dhclient

When my Ubuntu 1.86 GHz Core Duo box went down, I tried to ssh to it through my OpenSuse box. For this, I reinstalled the dhcp daemon, dhcpd to the latter. But now, I have another problem with this OpenSuse box.

Ever since I reinstalled dhcpd on OpenSuse, everytime the networkmanager tried to get an ip address from dhcdbd – the dhcp DBUS daemon, it recieved a link local address. After going through the system log, I found out that the dhclient didn’t accept the command string used by dhcdbd to execute it. It just exited with the usage details everytime dhcdbd ran it at the request of the networkmanager to get the new ip address.

Then I realised since dhclient also got reinstalled along with the dhcpd, this might have caused the problem. However now I needed to know what that command string was and needed some way to find that out. This is where Snoopy helped me. After installing it and digging through the system log, I found out that dhcdbd ran dhclient with -H parameter that is used to pass the domain name.  Since the installed version of dhclient didn’t recognise this -H option, my networkmanager never got a new ip address. So it helped me resolve a part of the problem.

Only a part of the problem since it seems the my version of dhclient takes network interface down on the -x option, which is also passed in the command string. It seems to me that this -x option does something with the dhclient scripts but I am not sure what. Online help on this seemed a little vague to me so if someone reads this blog and knows about this then please, please, comment about this.

Problem: Log the details of all process ever run in system uptime. Solution: Snoopy

Linux landscape doesn’t seem to provide an out of the box facility that provides you the details of all the processes that have ever been run during the system uptime. Someone at ubuntu irc on freenode told me about Snoopy.

It has a shared library that provides a wrapper about the execv and execve system calls and logs the details using syslog. These details include the process ID, session id, the execution arguements and the id and the name of the user who executed the process.

This is achieved by appending its shared library’s path to /etc/ld.so.preload during the installation so its loaded before the libc objects when a process makes the execv/execve system call.

This tool proved very nifty for me in debugging a problem I was having with dhcp on my linux box running SUSE 10.2.

There have been no new updates to it in last 5 years. And it has a TODO list which includes finding out why logging the execve system call needs a workaround even though it internally calls execv. It also fails to run firefox which seems to have a problem with something between /etc/ld.so.preload and an audio related file in /proc. I’ll edit this blog with its details after finding more.

And actually I would like it to support a few more features . Such as a conf file with the options for what should be logged and to which file. The latter might mean using some other logging facility or adding one of its own to it, but I would find it very useful. For instance, I might want to see the snoopy logs for the past month by the day, letting me know if something odd ran on my computer. Syslog sometimes gets too cluttered with alot of noise for this.  Also, I might want to add the the functionality to get snoopy details through a socket rather than a file, making it easier to get these details from a remote computer.

But, I think there will be some features the snoopy can add which may or many not include the ones I mentioned above. I think we should pick up the thread and continue the work from where snoopy developers stopped.

I think a proc file for the basic snoopy functionality might not be a very bad idea. As clumsy as the procfs is found by many Linux kernel maintainers these days and this treads on the policy-in-the-kernel issue, many people just find it very convenient to use.

If you have used snoopy before, tell me if you think it should be developed furher or you think its just good enough as it is for what its meant for. If you haven’t and feel this would be useful for you, tell me about how you found/liked this tool.