ips: Intelligent process monitoring

My apologies for the quiet space yesterday; I had some holiday-related travel to suffer through, and it wasn’t possible to update until this morning.

In return for your patience, I would like to offer ips, an intelligent process monitoring tool that has a lot in common with things like top, or perhaps procps.

If I understand ips correctly, most of its data is procured through /proc, and translated into an abbreviated format that is displayed in the style you see above. The details of the Summary section would require a little more space than I can afford today; take a look at the man page for a breakdown.

ips strikes me as both highly flexible and relatively easy to control; what you see above used the loop, curses, sort, noroot and a few other flags, for a relatively easy-to-follow top-like monitor. There are a lot of other options to pull from though.

ips also has a “graphical” mode that I feel I should mention, but it’s not particularly spectacular. Take a look if you like.

ips is in Debian, but I don’t see it in Arch/AUR, and I can’t find an original home page. It’s a little difficult to pin down since the name is “ips,” and quite a few other things obscure my searches. It’s a piece of cake to build ips in Arch from the Debian source though, so it’s not a huge issue.

I like ips, but it’s a little overkill in some respects, and isn’t quite as brief and quick as something like htop or just plain top. Still, if you’re looking for something unconventional and less popular than those two, ips is an idea. ips … the hipster process monitor. 🙄

pscpug: Nothing to do with pugs

The world needs good, accessible system monitors. It’s just a generalized rule. I can complain about an overabundance of music players or Tetris clones, but I don’t think anyone ever gets weary of seeing a new way of viewing their system information.

pscpug is a simple vertical scrolling process monitor that displays its results as a sparse bar graph.

It took me a while to get a decent screenshot, mostly because the applications I use are usually text-based, and it seems their process usage over time seems fairly flat. Pale Moon didn’t let me down though.

pscpug is terrifically simple, and terrifically useful. Feed it the pid of an application and you get a bar graph that refreshes at intervals, showing CPU drag. That’s all. There are only three flags — one for a different refresh rate, one to suppress its closing display of statistics, and one to switch to a generic data collection mode.

No color, but I’m willing to overlook that. No line-drawing characters, which may or may not be a good thing, depending on your system.

It’s very simple to control, very simple to read, and very simple to run. And it would look good on a shelf with top, tload or maybe nload.

And that’s all I can say about it. It does what it promises and doesn’t make a mess of things. Nice work. 😉

cv: The coreutils viewer

The other C-program I have today is a coreutils viewer, appearing as cv on Github. No, just for the record, I don’t dredge Github looking for new material. As it would happen, most titles these days are submitted from readers, and thrown into the hat.

This one was relayed to me by e-mail, and I realized later that I actually had it on my list as coreutils-viewer, so it’s possible I copied that name from elsewhere on the Internet. Regardless. …

Some other tools to amplify the output of core utilities — like pv or Advanced Copy — attempt to integrate themselves into the command, or pipe through it. cv, as you can see above, takes the sidelong approach by checking for running instances of dd, cp, mv, grep and a bunch of others, and showing their progress as a summary.

It’s an interesting solution to the long-standing issue of less-than-communicative programs, like cp. And goodness knows those have bothered me for quite some time.

cv has a few options to keep you busy; it has a monitor mode with -m, that will loop until processes finish, and another monitor mode with -M which will loop indefinitely, allowing you to keep it on screen as a kind of coreutils process monitor. I like that.

And there is a filter option with -c that lets you trim the display to only one particular process. Not much more than that, but simple is best. 😉

I think I shall keep cv on board for a little while longer. I like the idea of having a continuous monitor of coreutils processes, even if I am quickly approaching a system made up completely of monitors, and nothing actually doing any work. 🙄

screen: The granddaddy of terminal multiplexers

I was for a very long time a faithful user of GNU screen.

That has mellowed somewhat over the past few years, partly because tmux — I must admit — is leaps and bounds beyond what screen can do, but also just because there are other options too.

Things like dvtm, or even twin, which both handle the concept of multiple-terminals-one-screen in their own fashion.

Any of those three can do … somewhat something similar to what screen does, and have probably all seen more improvements over the years than screen.

I hold no one responsible for screen’s slow spiral into staleness; in fact, if anything, that makes screen quite easy to figure out: There is plenty of discussion about screen and how it works … even if some of it isn’t flattering. 😯

It may be the ugly stepmother of terminal multiplexers, but you can’t deny that it does what it claims. And in the realm of console-based software, that alone is sometimes enough to get by. In my book, anyway. 🙄

Postscript, 2014-04-20: Wouldn’t you know it, only a day after whining about years without updates, this trickles down the pipe to my lowly Arch install.

You could knock me over with a feather. 😯 Ask and ye shall receive, apparently. 😕

screenify: A tetchy little tool

I have screenify on my list, and I think it’s a little out-of-order to speak of it before recapping screen proper. And since screenify strikes me as a little less than practical, I’ll just skim through it. There isn’t much to show anyway.

screenify should do much like what reptyr does — yank a running process into another terminal, but I haven’t met with much success.

Documentation is very scant for screenify. I got it to work once, basically following the crude steps in this zsh mailing list reply, but it hasn’t worked since then.

If I understand properly, these are the steps:

1. Start your process in one terminal.
2. Use CTRL+Z to pause it.
3. Then disown the process, which should free your terminal and if you’re lucky, show the PID of the free-spinning process. If not, check top or another tool.
4. Now from within screen, use screenify PID and you’ll get some rambling text along with a confirmation.
5. From yet another shell, issue kill -CONT PID, which should redirect the output into your screen session.

Like I said, it worked for me once, but never again. Just dumb luck, I guess.

And processes other than very simple, single-PID, non-console-applications don’t seem to follow through. In other words, bc, htop and alpine all refused to jump between terminals for me.

So I’m not sure what I did. It might be that it works better for you than me, but it will rely on screen in the first place (which I know is not the favorite terminal multiplexer these days) and gdb … at least it did for the Arch version. 🙄

If you get it working or can explain it better, please share. I have a feeling this is another one of those things that will do its job correctly under specific circumstances, and I don’t want to sell it short. 😕

reptyr: Pull the rug out from under your tty

I have tried to put together a gif of reptyr in action. I really wanted this to work, but I’m running aground of a few quirks. See if this makes sense:

reptyr should allow you to detach a process from a tty session and yoink it into another one … if I understand the underlying idea.

So with bc running on one tty, I can yank it to the other by feeding its PID to reptyr.

Essentially you get a similar effect as you might with screen or tmux, detaching and allowing the process to continue, but freeing up the original tty.

I can see where this would be very useful for applications you started without screen/tmux, then don’t want to end.

It’s not quite working perfectly for me though, but part of it was fixable. The home page mentions the need to do this, as root:

echo 0 > /proc/sys/kernel/yama/ptrace_scope

and without it, all I got were error messages.

In addition, as you can see in the gif, there seem to be some issues with typed text not showing up in the receiving terminal. I’ll look into that, and see if there’s a way around it.

But some applications, like htop, happily jumped from one terminal to another, without skipping a beat. mc jumped, but didn’t refresh the screen until I pressed a key. bc, as you can see, seemed to respond, but lost its echoed text. It still showed results, just not the text I entered.

Those small quirks aside, and from the perspective of pure function, this is definitely a keeper. For all the times I’ve ever had to quit one session and move to another, and start over, reptyr would have saved me the trouble.

A coveted K.Mandla gold smilie for reptyr: 😀

procmail: May I refer you to someone more knowledgeable?

Sorry for the silence yesterday; Thursdays are still just too busy to tinker with computers, aside from real-life mission-critical issues. 🙄

It’s probably just as well, since one of today’s applications is procmail, and I am woefully underqualified to describe it.

I understand that it can forward, arrange and otherwise manage mail on your own mail server system, as well as some other nifty tricks.

But as far as I can tell it would require me to have an entire array of procmail, fetchmail, sendmail and other mini-applications working before I could get a decent screenshot.

Which again, with my piddly little Gmail accounts, makes me about the least qualified person to preach about it. 😦

So I will refer you to someone more knowledgeable, and by that I don’t mean DuckDuckGo Lite.

And what does K.Mandla always rely on, when in uncharted realms? Well, the Arch Linux wiki, of course. 😉

nice: It’s nice to be nice to the nice again

You know nice. We all know nice. nice lets you dedicate more processor muscle to an application, and hopefully get things done faster.

And that’s about it. A couple of things are worth mentioning, I suppose.

1. nice takes a range of 19 to -20. Minus 20 is the highest priority, and 19 is the lowest.
2. renice changes the value for a running process.
3. You can adjust the niceness of an application with the -n flag.
4. You can set lower and raise your own process between 19 and 0, but to push it higher (meaning, give it values less than 0), you have to have administrator privileges.

nice and renice are useful to a point, and that’s the last thing I wanted to note. It’s only going to do you good if the application is spending a lot of time on your processor.

If it’s writing to your hard drive or somehow bottlenecked by another component in your system, renice-ing it probably won’t make a difference.

In those cases, check ionice and other … nice … tools. 😉

ionice: It’s nice to be nice to the nice

I don’t use ionice as much as I should. I know better, but it’s always an afterthought to me. Mea culpa.

ionice works where nice doesn’t. The best example I can think of is laggy behavior on disk transfers, like copying a giant file from one place to another.

You can nice the copy process all you want, but you’ll probably still sense some lag, because you’re just devoting more processor priority to cp, which isn’t where the problem lies.

To that end, next time you are waiting for a big file to decrypt, or you’re splitting volumes in the background, try. …

sudo ionice -c3 -p###

where ### is the process number for the copy process or gnupg or split or whatever. Class 3 sets it to “idle,” meaning so long as nothing else needs disk access, this process can do as it wants. Otherwise, it takes a back seat.

I think I first learned about this from jdong’s website, years ago. The page is still there, and so is a gimmick to switch your whole shell process — and therefore everything subsequent that you start from there — to idle process. Take a peek; it’s a short but useful read.

ionice is part of util-linux. 😉

htop: Needs no introduction

Seriously, I doubt very much there are people left in the world who don’t know about htop.

Not including it would be a blasphemy though. In a very real sense, htop has everything I look for in a well built console application.

Color galore, svelte profile, clean line drawing, menus for configuration and commands.

And more customization than you can shake a stick at. Most people know htop, but not many know how deep the rabbit hole goes. Take a look at some dork’s lame post from years ago, for an idea.

I don’t need to introduce htop because it’s well done, and for that reason most everyone knows about it. The price you pay for fame, I suppose. 😉