Tag: psmisc

  • psmisc 23.0

    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.

    (more…)

  • psmisc 22.21 Released

    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:

    • If you started a process and then spawned some threads and then decided to change the names of the threads, pstree would show the “old” name, it now shows the correct new name
    • pstree has a new flag (-N) for namespace support, thanks Aristeu for the patches
    • Previously fuser -M flag only worked if it was before -m, now it can be either order

    The Debian psmisc package should be out in the next few hours.

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

     

    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
  • psmisc 22.13, gjay 0.3.1-2 and son 2.0

    Two updates for Debian today.

    I’m the upstream for psmisc and 22.13 finally got released, which also meant 22.13-1 Debian package got released too. There was some delay to it (see below why) but it is now out.  Unless you run a mips or superH architecture, there is not really any exciting changes, but should make it compile for those two architectures and then at least get the mips buildd underway so the versions all line up.

    Secondly, gjay had two minor bug fixes and was updated.  If the analysis daemon kept playing music instead of looking at it or the vorbis files were not being recognised, then this new version will help there.  The mpg123 command line patch will be rolled into the upstream too.

    I’m also working on getting gjay to work with the Exaile player.  If you want it to work with your player the easiest thing is to send me patches or code snippets that do the following:

    • Detect your player is running
    • Can give me the currently played song, preferably the filename of it. Exaile doesn’t so I’ll put it a kludge to guess it from title and artist
    • Remotely send a playlist to your player and get the player to start

    Last of all, my second son was born last week. It’s back to those night feeds again and is probably why I’ve not written as much code as I normally would; but I wouldn’t change that either.

  • Updated: psmisc, gw6c and gjay

    Time away from work and its been either raining or hot. So I’ve updated and released some software.  It always seems to happen there is a lot of Free Software development during the breaks.

    psmisc got a bunch of updates, including a new program called prtstat which formats the stat file in the procfs for a pid in (hopefully) a nice way.  No sooner had I released the latest update when a bug report came in. It seems fuser -m -k is a little too happy about killing itself. The fix is in the CVS but anoying I missed that.

    Next up was the Debian gw6c package. I was asked why it didn’t get moved from unstable to testing.  The problem is that while Linux has iproute, kfreebsd does not so the lack of a dependency was stopping it transitioning.  To make matters worse the freebsd template was missing from their package.  After some deb-substvars evilness to fix the dependencies and some dh_install overrides in the debian/rules file it should all be happy when its finished.

    Finally, I miss having good random playlists. I’m too lazy to make them myself so I use some random thing which often gives me rubbish.  A program called Gjay used to be in the Debian archive but got removed, mainly because the upstream stopped supporting it.  I can write C (the programming language its written in) and I wanted to use it, so I fixed it.  My version is 64-bit clean, so it works on my amd64 and it works with audacious not the old xmms which is great.  More importantly, it compiles, it runs and it even works properly.
    I’m just wondering if I want to release it out to the wider world or not.