Results tagged “Linux”

Most of the time you can trust the times you see in programs such as ps and top within Linux, but there are those other times where you just want to check what is going on.

First up, if you're using a FreeBSD system and the procps Linux tools, you're out of luck because a lot of the procfs is broken.  You're almost guaranteed to get wierd results.

Jiffies and Hertz
The first thing to find is your jiffies.  This is the number of clock ticks per second.  There are two main ways of doing it.

The first, and more difficult way is to add up the cpu numbers in /proc/stat, divide it by the first number in /proc/uptime and divide it by the number of cpus.

My cpu line in /proc/stat looks like:
cpu  1267430 145826 552700 137029699 905086 8295 17885 0 0

and my /proc/uptime is:
695317.99 1370303.58

I've got 2 cpus on this system so the calculation is:

(1267430  + 145826 + 552700 + 137029699 + 905086 + 8295  + 17885 + 0 + 0 )  / 695317.99 / 2
which equals 100.

The second way is to use getconf, with the command "getconf CLK_TCK" which again on this system gives you 100.

We call this value "Hertz" and is usually 100 or 1024 though for some architectures it is other values.

Start Time
For each process the procfs has the start time, but it is expressed as the number of jiffes since the computer was booted.  If we want to know the real "wall clock" time a process is started we have to start with number of seconds since epoch (for example using the time() function) subtract the number of seconds since the computer was booted and add the process start time from procfs.

The seconds since boot is the first value in /proc/uptime:
696141.85 1371857.53

The 22nd item in a procfs PID stat file is the number of jiffes since boot when the process started. We have to divide it by Hertz to calculate the number of seconds.
27139 (bash) S 11942 27139 27139 34821 5200 4202496 5500 25537 0 14 40 16 18 15 20 0 1 0 69446639 23433216 1378 18446744073709551615 4194304 5082140 14073724008 6512 140737240085456 140127945249678 0 65536 3686404 1266761467 0 0 0 17 1 0 0 0 0 0

To get the start time, take the current time, subtract the boot time and add the process start time.
perl -e '$nowstr = localtime(time() - 696141.85 + 69446639 / 100); print $nowstr, "\n";
Mon Jul 12 22:20:07 2010

Unless you are very quick, you will have to take a few seconds off because the time() function will be now, while the values from the proc files will be a few seconds earlier as it takes time for you to cut and paste.


1
OK, ok, i got a chroot and pbuilder now. So that should, I hope stop any more FTBFS bugs about missing depdendencies.

procps got uploaded that fixes some important bugs, but mainly they were small fiddly things. About the most significant enhancement was pmap now has a real working -x flag.  It looks a lot like some of the other pmap programs out there and shows the RSS and Dirty bytes per map. Let me know if its useful or not.

However there still is 48 bugs in the package, so if you're feeling game wander over to procps bug page and have a look around, but here are some more interesting ones, such as why would a process start time be earlier than the boot time? Bug 408879 has this problem

Now, a nice can of worms is in a Linux system, what is free memory?  What should the "free" program report?  Currently free just reports what it sees in /proc, but in Bug 565518 should the slab count be taken out?  I certainly won't be making any Debian-specific changes here as you could get different numbers depending on your distribution, or even worse the age of you Debian system.

procps is also my first attempt at using git-buildpackage which I found very helpful. There was one problem with it and that is how it works with the quilt patch program. If the quilt patches are applied, git doesn't know this and says all the files have changed. I know its how these two programs are supposed to work but its a little annoying.
1
Close