Dropbear

Tag: procfs

  • procps 3.3.12

    The procps developers are happy to announce that version 3.3.12 of procps was released today. This version has a mixture of bug fixes and enhancements. This unfortunately means another API bump but we are hoping this will be fixed with the new library API coming soon.

    procps is developed on gitlab and the new version of procps can be found at https://gitlab.com/procps-ng/procps/tree/newlib

    procps 3.3.12 can be found at https://gitlab.com/procps-ng/procps/tags/v3.3.12

    (more…)

  • Displaying Linux Memory

    Memory management is hard, but RAM management may be even harder.

    Most people know the vague overall concept of how memory usage is displayed within Linux. You have your total memory which is everything inside the box; then there is used and free which is what the system is or is not using respectively. Some people might know that not all used is used and some of it actually is free.  It can be very confusing to understand, even for a someone who maintains procps (the package that contains top and free, two programs that display memory usage).

    So, how does the memory display work?

    (more…)

  • procps 3.3.11

    I have updated NEWS, bumped the API and tagged in git; procps version 3.3.11 is now released!

    This release we have fixed many bugs and made procps more robust for those odd corner cases. See the NEWS file for details.  The most significant new feature in this release is the support for LXC containers in both ps and top.

    The source files can be found at both sourceforge and gitlab at:

    My thanks to the procps co-maintainers, bug reporters and merge/patch authors.

    What’s Next?

    There has been a large amount of work on the library API. This is not visible to this release as it is on a different git branch called newlib. The library is getting a complete overhaul and will look completely different to the old libproc/libprocps set. A decision hasn’t been made when newlib branch will merge into master, but we will do it once we’re happy the library and its API have settled. This change will be the largest change to procps’ library in its 20-odd year history but will mean the library will use common modern practices for libraries.

  • procps-ng 3.3.9

    Procps version 3.3.9 was released today.  As there has been some API changes and fixes which means the library has changed again.  There is a fine balance between fixing or enhancing library functions and keeping the API stable, with the added problem it wasn’t a terribly good one to start with.

    Besides the API change, the following changes were made:

    • kernel namespaces support added to skill, pgrep, ps and top
    • pidof was reimplemented from scratch (replacing sysvinit pidof)
    • ps has configurable libselinux support (–enable-libselinux)
    • ps provides for display of systemd slice unit (–with-systemd)
    • free can once again report non-zero ‘shared’ memory
    • sysctl provides ‘–system’ to ignore missing /etc/sysctl.conf
    • watch interval capacity was increased – debian #720445
    • pwdx no longer fails in a nonexistent locale – debian #718766
    • top clarified summary area Mem/Swap stats – debian #718670
    • top batch mode -w (width) abend fixed – debian #721204
    • top man page removed ‘Bd/Ed’ mdoc macros – debian #725713
    • top no longer clears screen at exit – redhat #977561
    • top adapted to potential libnuma stderr message – redhat #998678
    • top added missing batch mode newline – redhat #1008674

    Tar file is at sourceforge at https://sourceforge.net/projects/procps-ng/files/Production/

  • 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