Useful but Unknown Unix Tools: watch //at 22:18 //by abe

Yet another useful tool of which at least I heard quite late in my Unix career is “watch”. For a long time I wrote one-liners like this to monitor the output of a command:

while :; do echo -n "`date` "; host bla nameserver; sleep 2; done

But it’s way shorter and less error-prone to use “watch” from Debian’s procps package and just write

watch host bla nameserver

The only relevant difference is that I don’t have some kind of history when the output of the command changed, e.g. to calculate the rate with which a file grows.

You can even track the output of more than one command:

watch 'ps aux | grep resize2fs; df -hl'

Also a nice way to use watch is to run it inside GNU Screen (or tmux or splitvt) and split up the terminal horizontally, i.e. show the output of watch in one window and the process you’re tracking with the commands run by watch in the other window and see both running at the same time.

Update, Sunday, 28th of August 2011, 17:13h

I never found a useful case for watch’s -d option which highlights changes to the previous run (by inverting the changed bytes), but until now three people pointed out the -d option in response to this blog-posting and weasel also had some nice examples, so here are they:

Keep an eye on the current network routes (once per second) of a host and quickly notice when they change:

watch -n1 -d ip r

Watch the current directory for size or time stamp changes of its files:

watch -d ls -l

The option -d only highlights changes from the previous run to the next run. If you want to see all bytes which ever changed since the first run, use --differences=cumulative.

Thanks to Klaus “Mowgli” Ethgen, Ulrich “mru” Dangel, Uli “youam” Martens and Peter “weasel” Palfrader for comments and suggestions.

Useful but Unknown Unix Tools: Kill all processes of a user //at 22:15 //by abe

I already got mails like “What a pity that your nice blog posting series ended”. No, it didn’t end. As announced, I knew that I won’t be able to keep up a daily schedule. It worked as long as I had already written the postings in advanced. But in the end the last postings were already written just in time and then I ran out of leisure and muse for a time. But as I said: It didn’t end, it will be continued. And this is the next such posting.

Oh, and for those who tell me further tools, I should blog about: I appreciate that, especially because that way I also hear about tools I didn’t know about. But why just telling me and not blogging yourself about it? :-) At least those whose blog is part of Planet Debian or Planet Symlink anyway really should do this themselves. I’d really like to see also others writing about cool tools. I neither have a right on the idea nor on the name of this series (call it meme if you want :-), so please go on and publish your favourite tools in a blog posting, too. :-)

And for all those who want to join me and Myon blogging about cool Unix tools, independent if listed on Planet Debian or Planet Symlink, I encourage you to offer a separate feed for this kind of postings and join us on Planet Commandline.

Anyway, here’s the next such posting:

As system administrator you often have the case that you have to kill all processes of one user, e.g. if a daemon didn’t properly shut down itself or amok running leftovers of a GUI session.

Many use pkill -SIGNAL -u user from the procps package or killall -SIGNAL -u user from the psmisc package for it. But that’s a) quite cumbersome to type and b) is there a chance to forget about the -u and then bad things may happen, especially with pkill’s default substring match, so I prefer another tool with a more explicit name:

slay

slay has an easy to remember name (at least for BOFHs ;-) which is even quicker to type (alternating one character with the left and the right hand, at least on US layout keyboards) than “pkill” (all characters to type with the right hand), and has the same easy to remember commandline syntax like kill itself:

slay -SIGNAL user [user …]

But beware, slay is…

… not only for BOFHs, but also from a BOFH

It has a “mean mode” which is activated by default. With mean mode on, it won’t kill the given user but the user who called the program if it is invoked as an ordinary user without root rights. *g*

Interestingly I never ran into this issue despite I use this program often and for many years now.

But some Ubuntu users did, probably because adding a sudo in front of some command is easier to forget than doing an ssh root@localhost or su - beforehand. They even seem to be so desperate about it that they forwarded the issue from Launchpad to the Debian Bug Tracking System. ;-)

But to be honest — even if I was very amused about those bug reports — isn’t this issue “grave”, as it causes very likely (unexpected) data loss?

Now playing: Monzy — kill dash nine (… and your process is mine ;-)