Careful with PIDs

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.

 

  • Linux has init  with PID 1 and PPID  0. There is no process 0
  • FreeBSD has init with PID 1 and PPID 0. Process 0 is kernel and exists and has PPID 0
  • Hurd has init at 1 with PPID 1. Process 0 is proc and has PPID 1

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....

 

Enhanced by Zemanta

Australia Data Retention Scheme Stalled

It’s been reported in the mainstream media that the Australian Data Retention Scheme has been referred to another committee, effectively delaying it to after the next election.  The Scheme was part of a broad review of the various security agencies powers and how to streamline them.  The initial paper originally stated that retention would be for up to 2 years for parts of the data set, without really specifying what the data was.

There has been various ideas of what this data is, depending who you ask and when.  Some documents state it is only the accounting data; that user X used IP address Y at time Z, while others state it is email logs and a third have been the previous two plus web logs.

There are many problems with a scheme such as this.  2 years of everyones web-browsing history is a desirable target for both legitimate and illegitimate access to that data.  Leaving aside would the access to the agencies get the right level of access; who else would want this data?  I’m sure that AFACT (Australia’s MPAA effectively) would like this data to go trawling.  The recent exposure of AAPT‘s data by Anonymous shows that there may be some other means of obtaining this data.

I actually wonder, if the scheme was in, what they would find?  Take email for example; my email leaves my computer and directly communicates with the destination mail server. If someone pulled my email records they’d show very little information.  If it is too hard to run your own mailserver, I’m sure the enterprising no-gooders that they are so interested in finding can work out how to buy a remote mailserver somewhere.

If that’s too hard, there’s always gmail with https, or VPNs, or TOR, or.. well there are plenty of options.  It probably comes down to how resourceful (if thats the word) people are.  By the way, mentioning https reminded me of the great little plug-in called HTTPS Everywhere by EFF.

I’m glad to see that this legislation is stalled. To me the paperwork I saw appeared to be saying that they got some bad guys with what powers they have so they will catch more with more powers; therefore more powers are good, OK?  It’s a rather simplistic view of the world.  My only worry is its not stopped, just stalled so it might be re-animated in future.

 

Enhanced by Zemanta

Context sensitive menus with GtkTreeView

A project I now maintain called GJay uses the GTK+ toolkit and has a GtkTreeView that shows the directories and the songs in them.  I was wanting to add a context sensitive menu on that view so that you could do things to the item you have right-clicked on; generally file specific things like give me information about this song or queue it to play.  My only problem was, how to do it?  A few Google searches showed things that were almost, but not quite, what I was after.  The main problem being either the documentation was incomplete or it assumed I was after the selected field (the row I may of left-clicked on) and not the one I right-clicked on to get this event.

This GtkTreeView uses a store where NAME_COLUMN is defined at 0, meaning it is the first column. The program uses this column to store the filename of the song.

So first I needed to create an event to kick things off, we need to connect the “button-press-event” to our tree_view, which calls a function in this case view_on_button_pressed.

 g_signal_connect(tree_view, "button-press-event",
   G_CALLBACK(view_on_button_pressed), NULL);
gboolean view_on_button_pressed(GtkWidget *tree_view,
                                GdkEventButton *event,
                                gpointer user_data) {
  GtkTreeSelection *selection;
  GtkTreePath *tree_path;
  GtkTreeModel *tree_model;
  GtkTreeIter tree_iter;
  gchar *name;

  if (event->type == GDK_BUTTON_PRESS && event->button == 3) {
    tree_model = gtk_tree_view_get_model(GTK_TREE_VIEW(tree_view));
    if (gtk_tree_view_get_path_at_pos(GTK_TREE_VIEW(tree_view),
          (int)event->x, (int)event->y,
          &tree_path, NULL, NULL, NULL)) {
      if (gtk_tree_model_get_iter(tree_model, &tree_iter, tree_path)) {
        gtk_tree_model_get(tree_model, &tree_iter, NAME_COLUMN, &name, -1);
        g_print("rc name is %sn", name);
      }
    }
  }

So a breakdown of what my callback is doing:

  • Line 1:The callback’s widget is the GtkTreeView widget we connected the signal with
  • Line 10:Checks the event was a button press and button #3 (right button)
  • Line 11: Find the GtkTreeModel from the given GtkTreeView
  • Lines 12-14: Get the GtkTreePath that the right-click was sitting at by using the event coordinates.
  • Line 15: Convert the GtkTreePath into a GtkTreeIter
  • Line 16: Find the actual value we put into this row.

The program, now that it knows the song title, can then go off and generate a menu for that song.

Enhanced by Zemanta

debhelper versions – Guilty!

After reading Jakub’s pet peeve about debhelper build-dependencies I decided to check my own and sponsored packages to see how they fare.

find debian/ -type f -name control | xargs grep -h -o 'debhelper (>= 9[^)]*)' | sort | uniq -c
      2 debhelper (>= 9)
      2 debhelper (>= 9.0)
      3 debhelper (>= 9.0.0)
      1 debhelper (>= 9.20120115)

Oops! Something to fix in all subsequent releases.

Enhanced by Zemanta

Dejagnu tips

Both the procps and psmisc projects use Dejagnu for their testing.  It’s interesting to try to understand how it all works and learning a new language TCL.  One of the big problems with Dejagnu is its documentation which is very sparse. So here are two things I’ve picked up along the way for a reference for myself and others.

Locale

We recently had a bug report on the procps list where tests for w failed for someone when the headers were shown.  After a some further debugging it was a locale problem, where the testsuite was looking for a number like 3.14 but the tester was seeing 3,14. There are many ways around this but for us it was to set the locale, with the following line in config/unix.exp after suggestions by Mike Frysinger should fix it.

set env(LC_ALL) "C"

Cleaning Up
The documentation on this function is awesome! A title “Cleanup Procedure” and one line “cleanup()”.
That’s all you get. The cleanup proc or function is called at the end of the testing. I use it
to remove temporary files and things like that.

proc cleanup { } {
        global test_file
        exec rm $test_file
}