Dropbear

Tag: Linux

  • procps-ng 3.3.7 Released

    procps-ng version 3.3.7 was released today.  It has some new and interesting features in the top program that Jim has been busy working on.  There is a new filter feature which can exclude fields that match a value for example. The remainder of the changes are small bug fixes and getting the compile warnings count down with -Wall enabled. The library revision was updated but this did not involve an API or ABI change.

    procps-ng can be downloaded off the sourceforge page which has the current and previous releases stored there. Alternatively you can visit our gitorious page if git fetch is more your thing. Debian packages will be going into experimental until the freeze is over and we get things unblocked.

  • procps 3.3.6 and Mudlet 2.0

    Mudlet - Graphical MUD clientYesterday was a busy Debian day for me with the release of not one but two packages.

    procps

    procps version 3.3.6 was released both as an upstream and a Debian package.  While there were many bug fixes in this release, the main new feature for it was the top inspect feature.

    The top inspect feature allows you to run top in the normal way then you can inspect a specific process you have selected within top for more information.  Examples of this include fuser or lsof type output to see what files or libraries are open but really the limit is how clever the operator is and how often you would need this information.  Even scripts can be run off this feature if you have some customised or cooked output you need to see.  Once the output is there, you can search for text.

    There will be a small hold-up with the Debian packages as the section for the  library has been moved to libs, where it should be. At least I think that’s why there is a delay.

    procps infrastructure

    procps currently has only an email list and a gitorious git repository.  While this works most of the time, there are two main problems with this setup.

    The first is that the only two ways you can report bugs is send an email to the list or create a git merge request. The email has the problem with tracking and gathering history while the git sets the bar pretty high for reporting something has gone wrong.

    Second problem is there is no tarball file repository.  gitorious does have the feature of downloading tarballs of the tag checkpoints, but this is the raw repository.  When you make a tarball with “make dist” there are some generated files included in the tarball that don’t appear in the gitorious ones, which means its not a simple for some as you expect.

    So I’ll be creating a project for these two features soon.  Not sure where they will be but I use sourceforge for both these for a few other projects so that might be where they end up.

     

    Mudlet

    Mudlet, the multi-user dungeon or MUD client, has finally made it to version 2.0!  It looks a lot more stable and polished at least from the scripting side than the previous RC versions but has all the features that we’ve come to expect with it.  The most important thing is that the developers have finally put a line in the sand and said “this is version 2.0”.  The Debian package was uploaded yesterday and should be on its way to your local mirror soon.

     

    Enhanced by Zemanta

  • procps-ng 3.3.5

    Are you using procps 3.3.4?  My suggestion is you don’t!

    An API change slipped through which mean if you tried to run procps 3.3.5 on libproc 3.3.4 it did strange things. One of those strange things is ps ax crashes. Top looked rather interesting as well.  This in turn upsets the boot sequence around mounting drives so you get a horrible mess.  The problem is the testsuite didn’t catch it because we’re not testing the API yet and the binaries use the libtool hack to use the library in the build directory.  Lucky for me I only updated manually the binaries and not the library so I saw it early.

    procps 3.3.5 was released tonight and it has the SONAME bump ,so we are not at libprocps1 not libprocps0.

    Enhanced by Zemanta

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

     

    Related articles
    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

  • pam bugs hurt

    I did some upgrades of what seemed like a million packages today on my Debian sid computer.  I was doing this remotely and when I tried to ssh back in I got kicked out after entering my password, hmmm.

    OK, so I waited until I could get in front of it and tried to login to the console and was greeted with the message “Cannot make/remove an entry” and kicked out, even as root; double hmmm.

    So it was boot into single user time which, thankfully worked. bash loaded ok so it wasn’t a shell problem.  However su failed which means we are into pam problem territory.  I found a bug report that sounded like my problem, but with no clear solution except upgrade in Ubuntu.

     

    The solution was pretty simple for me.  It’s something funky with /etc/pam.d/common-sesssion and a simple ‘/usr/sbin/pam-auth-update’ fixed it for me.

     

     

    Enhanced by Zemanta

  • procps-ng 3.3.3 released

    top
    Top in colour mode

    This weekend procps-ng version 3.3.3 was tagged and released for distribution.  There have been many patches and fixes involved in this release as we move from an unchanging static sort of code into something that is easier to maintain and build on various architectures.  The good thing is I’m down to 1 or 2 patches in the Debian archive which is a big change from the 30 or 40-odd I used to carry.  For the sole metric of getting that number down, the project fork has been a success.

     

    There were some post-release bugs I found and these were more to do with the various options turned on or off rather than what you’d see if you did the basic ./configure && make.  One of them was how the version numbers are defined in git, but would only appear if certain files were older than others (such as aclocal.m4 versus config.h.in)  Others were when certain features were turned on.  The make check doesn’t see all of this because it uses the default configure flags.

    One annoying thing of the autotools is conditionally installing man pages. This is where you don’t or cannot compile a binary so you don’t install the corresponding man page.  The automake documentation is of course obscure about this but I cannot see a way of distributing only a man page, so we have this fiddle where a file goes into dist_man_MANS or EXTRA_DIST depending.

    Interestingly, there has been some bike-shedding around Fedora-land (see the link below) regarding the name procps-ng versus procps.  Debian is lucky that we do have different upstream and package names (though not ideal) so apt-get install procps still gives you procps.  There also has been discussion about merging procps-ng into util-linux whichin the short-term won’t be happening.

    Related articles
    Enhanced by Zemanta

  • psmisc 22.16 Released

    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.

    Test Processes

    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.

    Enhanced by Zemanta

  • VMware Player on Debian

    For various reasons, having vmware running on my desktop would be kind of useful.  VMware provide a Free (as in beer) version of their software called VMware Player. I downloaded the file VMware-Player-4.0.2-591240.x86_64.bundle off their website and tried to build it.

    It failed to build. Given my previous lack of success with VMware server, I wasn’t too surprised.  What was surprising was it wasn’t too hard to fix it.  The problem was that the vmnet module would not compile and that was due to three things:

    • net device ops no longer has set_multicast_list (in netif.c)
    • the linux module header needs to be included to define THIS_MODULE
    • skb_frag_t has been redefined and needs an adjustment

    The patch is only a few lines and means I can compile vmware on my Debian sid computer running kernel 3.2.0-1

    vmnet.patch

    To use it, you will need to find where the modules are built, for me it is /usr/lib/vmware/modules/source

    1. mv vmnet.tar vmnet2.tar
    2. tar xf vmnet2.tar
    3. patch -p0 < vmnet.patch
    4. tar cf vmnet.tar vmnet-only

    With that you can run the player which will try to build the modules and you’re done!

     

     

    Related articles
    Enhanced by Zemanta

  • Unlucky sometimes

    Sometimes life throws little curves at you to see if you are still awake, today has been one of those days.

    fglrx is (apparently) fixed

    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 22.15 and buffer overflows

    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.

     

    Related articles
    Enhanced by Zemanta