On life right now

Oh boy, I'm dead tired.

Christmas vacations are closing in. Tomorrow my girlfriend, my daughter and I are going to see our parents and grand-parents which live a little east from where I live. It's a three hour drive, a short trip, but we plan to stay 10 days. Parents will know that this require to pack-in a lot of stuff, mostly for the baby.

I find it ironic that a 12 pound baby requires to carry as much stuff as two grown adults. And that's just "life support". We don't carry much extra things around.

Luckily my girlfriend is better than me at organizing, otherwise we would end up with pretty much everything missing.

It's unlikely you will see technical post here until I get back.

Projects

I have not had time to think much about the idea I was to write about some posts ago. My goal is to keep this blog on a technical blog, so I will try to summarize that idea here instead of waiting to have time for a bigger post.

I have started playing around with the little known ptrace syscall on Linux. My idea is to code a programmable variant of strace.

strace is a tool that allows you to see what system calls a program do on the Linux kernel. System calls are the functions in the kernel that can be used by the user program to do things. You might already know that it's not the GNU Libc that write on the disk. The kernel does. The libc, and other libraries, uses system calls to tell the kernel to write on the disk. That means if you know what system calls a program use, you get a pretty good idea what it is doing.

That's strace, in short. I could write a whole article with example and such but I'm sure there are better writes that already did so go it Google.

Since I've started coding under Linux, I've always found strace to be one of the most useful development tool available. It's actually useful beyond programming tasks. I have used it more than often to get more useful error message from malfunctioning programs.

What annoys me with strace though, is that it's sometimes very painful to extricate information from the thousands of calls done by a program. There is a lot of noise in a strace output.

With a programmable strace, I would like to be able to intercept just the information what I want, and do the interpretation of the data programmatically.

The most striking example of what I think is to track file descriptor leak. There are few system calls out there that return file descriptors. File descriptors are a limited resources to the process, and if they run out, the process will probably cease working.

Determining that file descriptor leak happen is easy. All you have to do is count the number of files in /proc/pid/fd.

Finding what is leaked, what it was used for and in what circumstance the file descriptor is leaked might be more complex. That is usually something I manage to accomplish with strace.

It would be faster to write a small program in an high-level language that could trap the system calls that return file descriptors and log what happens.

That's the idea that made me think about that project. That and the fact that it would be fun to code that.

What I need to investigate further is if I can do more than simply spy the program. If you can change return values of system calls, you can submit programs to a lot of strange error conditions. It would be easy to simulate a full hard-drive, for example, without needing to patch the GNU Libc. All that would be needed is a short program telling what to return when a child program calls the write system call.

That text is probably confusing as hell to users, and non-developers. Don't worry. If I find the idea implementable and useful, and if the projects takes off, I will certainly blog about it again.