killing a process in TCL

Suppose you had spawned a process in TCL and knew its PID and wanted to kill it? Sounds simple enough thing to do, right? This problem has plagued me for many months because some things you can assume on a normal system do not hold true on strange environments, such as build deaemons.

Seems simple enough, I started off with:

exec kill $pid

Except.. not every environment has the kill binary, and with that piece of code exec has to be a binary and not a shell builtin. The funny thing is that /bin/kill is in the procps package, which is the package having the buildd problems.

So next idea was to use command -v to check for the existence of kill and skip those tests that needed kill if not found. Good idea except, so I found out later, it also finds built-ins. That means we are back to problem #1.

There is a kill command in tcl, but it requires tclx. That seems excessive for just one little simple command. How can I run a shell out of TCL that runs the kill builtin? On the command line, something like below would do it.

/bin/sh -c 'kill 1234'

I was closer, but then hit TCL quoting hell. No matter what I (initially) did I’d either get the shell to complain or my variable to not be evaluated. In the end, I had to write it to a separate variable for the command line then apply that to the exec. Not perfect but at least it works now.

The resulting code (found in testsuite/config/unix.exp) looks like:

proc kill_process pid {
    set cmdline "kill $pid"
    if { [catch { exec /bin/sh -c $cmdline } msg]} {
        warning "Could not kill process: $msgn"

Perhaps there is a more elegant way, I’m certainly no star TCL programmer, but of all the combinations I saw this was the only that worked.

Sneak peek of top graphs

Jim has been busy as part of the procps-ng team that looks after top. Basically all the changes you find in top from around 2.7 or so are by him. Not satisfied enough with fixing top, making it faster and showing more fields, he has given us CPU and memory graphs.

He also thinks I don’t have enough colours (or as he would put it colors) on my top output so I’ve posted what the new top looks like for me so you can see the graphs and he can see my colours.

top, with colours
top, with colours


I think it is both colourful and useful addition. The colours have been available for a while now and the graphs will appear in the next upstream release of procps-ng.


Debian's procps 3.3.9

While the upstream procps which was released last week has a new pidof, the Debian package will continue to not have that binary and the

Debian sysvint-utils package will continue to have that file. That stops any messy procps splits and putting one part into Essential etc.

This may mean that one distributions pidof doesn’t quite work like anothers, but that has been like that already; which is why when I discussed the change as upstream I wondered where they found some of those flags I don’t have.


Enhanced by Zemanta

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

pidof moving to procps

pidof is a program that finds the PID of a named program. In some ways it is like a cut-down pgrep found in the procps package.  pidof currently sits in sysvinit-tools.

There are plans to move all utilities that use the proc filesystem under one package which will make the maintenance of them simpler, which in effect means moving pidof from sysvinit-tools to procps. The short-term bump should make it better in the long term.

Now as I wear two hats (Debian maintainer and procps upstream) there are two very important things I/we need to know.

  • If your Debian package depends on pidof being present, then we need to discuss dependencies. procps is generally installed on most systems but there might be corner cases. Possibly just depending on a specific version of procps will do it
  • If you, your Debian package or anything else (including other distributions) need the non-LSB options of pidof (ie they use -c -n or -m) then we (upstream) need to know about it. There are provisional plans not to support these options but they’re needed, or a subset is, then that could change.

Debian developers can chime in on the debian-devel email list, or email myself. If its an upstream issue then either email me, or even better, the procps email list

Enhanced by Zemanta