I had to go check but it has been over 3 years since the last psmisc release back in February 2014. I really didn’t think it had been that long ago. Anyhow, with no further delay, psmisc version 23.0 has been released today!
Update: 23.1 is out now, removed some debug line out of killall and shipped two missing documents.
Today as it was raining and I couldn’t do much gardening, psmisc version 22.21 was released. The files are located up on sourceforge at https://sourceforge.net/projects/psmisc/files/latest/download or at your favorite distro repository soon. Once again, thanks to all patch submitters, bug reports and translators for all their help in getting this out. Apologies to the translation teams for having two alpha versions.
So what does psmisc 22.21 bring you? Amongst a lot of minor bug fixes it has:
The Debian psmisc package should be out in the next few hours.
Quick question, what is the lowest Process ID you will find? Most people (myself included until recently) would be able to say that the lowest number is 1 for the init process. Plenty of programs including ps and pstree have this assumption.
This assumption bit me this week with Debian Bug 687829 where pstree on a kFreeBSD would not return and used 100% CPU. What was happening? Well it seems that kFreeBSD has a process ID of 0 and pstree used 0 for a fake root to the tree. So with a real and fake process #0 hanging around in pstree there was a strange parent-child circle (I’m my own grandad!) between init and process 0 meaning when the tree was walked things go around in circles.
The fix is basically to assume the tree starts at 0 and not 1 and that keeps things into perspective. So if you are wondering how inconsistent this goes, here is the list.
So Linux the root is init PID 1, FreeBSD it is kernel PID 0 and Hurd its init PID 1 with a child with PID 0.
Nothing like consistency! I do like the crazyness of Hurd where a child is created before a parent; nothing is normal in Hurd-land.
I have some temporary code going proving the problem with psmisc and FreeBSD, the tree now looks like what you can see below. This fix will also show up processes “hidden” under init that were previously hiding.
?()-+-acpi_cooling0(16)
|-acpi_thermal(15)
|-audit(10)
|-bufdaemon(18)
|-flowcleaner(22)
|-g_down(4)
|-g_event(2)
|-g_up(3)
|-hald-runner(547)---hald-addon-storag(569)
|-hald(546)-+-hald(548)---hald(549)
| `-hald-runner(547)---hald-addon-storag(569)
|-hald(548)---hald(549)
|-idle(11)
|-init(1)-+-etc....
psmisc version 22.16 was released today. It is a bugfix release that bascially fixes a problem around strings in C. Process name lengths are only supposed to be 16 characters long, so a 17 bye buffer is ok; until you have processes with brackets which means the string is 18 characters.
The next wrinkle is that at times the brackets are stripped out so matches fail because the lengths don’t quite line up. You’ll see this with the Debian 22.15-2 version of psmisc where killall won’t find long-named processes.
So, 22.16 fixes all that.
It really shows that psmisc needs a set of tests like procps has already. The difficulty with both is that its not simple in the DejaGNU framework to make test processes. These are not the programs within the package but other processes that the programs can work on. There really needs to be an equivalent to touch for processes just for this sort of thing. Creating processes is rather simple, but ensuring they go away is the tricky part, or they die with certain signals.
Sometimes life throws little curves at you to see if you are still awake, today has been one of those days.
I’ve had a long-running problem with fglrx on my laptop. The problem stems from ATI closed-source drivers with one of those laptops that has an ATI and Intel driver. It means I am basically using the slow Intel chip only. This morning I had enough and backed up my home and started to rebuild the laptop with Debian 6.0.3.
So I kicked off the very very slow process of reformatting the crypto drive (it has taken 5 hours and still going) let it gurgle on its merry way and started to read my email. One of the emails was that my bug about fglrx not working is closed, apparently it is fixed. If I had read that 10 minutes earlier, a simple ‘apt-get install fglrx-driver‘ would of perhaps fixed it; oh well.
My problem is now is do I move to the latest driver and hope their fix is my fix or leave it with some ancient version? My preference is the former; I only hope it works!
psmisc has a program called pstree which prints the set of processes in a tree fashion. It hasn’t changed much for quite a while. I released version 22.15 and the Debian package 22.15-1. 22.15-1 I also adopted the harden CFLAGS as suggested for procps.
I was a little surprised that I received an important bug. The report was saying I had a buffer overflow introduced in 22.15-1, but no relevant code had changed. The compiler options had done their job and stopped a buffer being overflowed.
But where exactly was the overflow? Running gdb on pstree quickly showed that it was line 267 of pstree.c which uses strcpy(). That function set off warning bells. The relevant code is:
PROC *new;
if (!(new = malloc(sizeof(PROC)))) {
perror("malloc");
exit(1);
}
strcpy(new->comm, comm);
Now comm is the short command name you find in /proc//stat. It is fixed in the kernel at 16 characters. The PROC structure has this field as 17 characters long, one extra for the NUL. I went and checked the Linux source and yes, it is still 16 characters long. The clue was in the name of the program that it died on.
#6 new_proc (comm=0x6111b0 "{console-kit-dae}", pid=1571, uid=0)
at pstree.c:267
That string is 17 characters long. The problem is that 16 characters is for the name only. If the name is in brackets or braces, then that 16 character limit doesn’t apply. The buffer overflow bug has been there for a long time, but only with the compiler flags did it become visible.
Given you need to read names out of the /proc filesystem and if someone can fiddle with that you have bigger problems it doesn’t seem to be too much of an issue. It should be (and is in Debian 22.15-2) fixed but is a nice example of the compiler catching bad things.