Tag Archives: system

sysdig: Information overload

I have seen several sites and software lists that include sysdig, usually with high praise for providing an unmatched level of insight into the inner workings of a system.

And that, I cannot dispute. I can’t think of a tool that spools quite the volume of raw data — and I do mean volume and I do mean raw — as sysdig can.


That was just a smidgin — a smidgin, I tell you — of what sysdig started piping to my terminal. Vast volumes of internal clock checks, software requests, hardware reports … you name it. Everything stamped and logged, and open for scrutiny.

In that sense, sysdig does a terrific job of giving you the aforementioned unmatched level of insight into the inner workings of your system.

My problem is, there is so much raw data and so much detail in the information, I honestly don’t know what to do with it.

Seriously: Barely 30 seconds or so of sysdig’s output, piped into a plain text file, resulted in 20 megabytes — and I spelled that out as megabytes so there wouldn’t be any confusion — of raw text data. And that’s on a 12-year-old desktop system running a smattering of desktop applications. I can’t imagine what kind of volume would appear in a proper, high-end system doing real work, like a web server.

On top of that, sysdig itself is a rather taxing application … or at least it is on the hardware I run. While sysdig is doing its thing, I get lags while typing, skipping music playback, etc., etc. It’s obvious that tracking detail at that level is imposing a serious drag on the system. Observer effect, anyone?

sysdig in Arch will build a special module that must be inserted to get sysdig to work. I didn’t try Debian yet; my Linux Mint machine is offline for a day or so, for misbehaving. (I also occasionally punish my TV for saying rude things, so this is not unexpected.)

I won’t duplicate the glowing praise that sysdig gets in other circles, just because there seems to be a heavy tradeoff in using it, from my standpoint. Yes, it will let you see every clock sync between your hardware and software, and you’ll see exactly when the downbeat of “Bring da Ruckus” leaves your music player and departs your speakers.

But you’ll need a degree of power to keep both the system and sysdig afloat at the same time. I’m guessing if your machine predates the Pentium 4 generation, you might have trouble with that. Just so you know. 😐

lsp: Think of this as “ls, plus”

One of the under-the-radar winners of the past year was sl. No, not that sl. The other sl. The one nobody seems to know about because of the ASCII train. πŸ™„

sl attempted to convey a little more information than the ordinary ls command, by adding color and groups and a few more sparkly bits.

lsp is another attempt, and as you can see, it has a firm grasp on the idea.

2014-10-03-6m47421-lsp-01 2014-10-03-6m47421-lsp-02 2014-10-03-6m47421-lsp-03

By default, lsp aligns file names and file types down the center of the screen. If you add the -l flag, you’ll get the same arrangement but with separation between groups. Add -s and you get human-readable file sizes. -t shows timestamps. And so on.

I do admit I like lsp for smart use of color, and for a more readable arrangement on the screen. No more using my finger to trace across the display, looking for a file size in a long list. And if you don’t like that centered style, there is a flag to left-align the whole business.

lsp also does you the favor of telling you how many files are inside directories, totals for files and directories, resizing itself to smaller or oddball terminal dimensions, and a few other nice touches. It is obviously the product of some forethought.

For negative points, I feel a little bit guilty that a large amount of screen space seems left open by default. ls -lha --color seems to pack a lot more information into a smaller space, whereas lsp will need a vertical dimension, primarily.

Along the same lines, combining flags — particularly lsp -lt imbalanced the centering across the screen, ruining the effect. lsp should probably take into account short file names combined with long, extended timestamps, and center a little more to the left, when it’s possible.

I should mention that building lsp required installing go, but doesn’t require it to run. So if you’re not comfortable with the 238Mb (?!) that is taken up by go in the Arch version, you can rip out go and still use lsp.

lsp is not in Arch/AUR or Debian that I could find, and time stamps in the git repo suggest updates within the past few weeks. So it’s another new program for you, wandering in the wild. … πŸ™‚

archey3 and alsi: What all the cool kids are doing

When I kept appending screenfetch with the phrase, “or something like it” earlier today, I was doing that because screenfetch has kindred in archey3 and alsi.

2014-09-09-6m47421-archey3 2014-09-09-6m47421-alsi

archey3 on the left, and alsi on the right. And as you can see, they differ only in presentation, and in the ASCII art.

Well, that’s not entirely correct, since there are some underpinnings that are different. screenfetch used scrot by default for a screenshot. archey3 uses imagemagick‘s import tool, but alsi seems content with scrot as well. All three have options that allow you to change that.

From what I can see, screenfetch might be the only one that supports distros other than Arch. I might be wrong on that point though, so don’t hold me to it.

screenfetch was a bash script, archey3 is a python program, and alsi is written in perl. And as you can see, each one pulls out slightly different information on your system — some even polling hard drives or graphics processors.

One or two take png screenshots by default, and jpg in the others (as you might be able to tell from the poor readability around the blues and grays).

And that’s about where the comparison ends. Of the three, alsi appears to be the most flexible, as far as which outside programs you can use, and what ASCII art will be displayed. Don’t necessarily take that as an endorsement though.

At this point, the question becomes one of preference: Whose art do you like best, what colors do you prefer, and what information do you want to share? A question of aesthetics, really. πŸ™‚

P.S., yes, there is an archey and an archey2. For purposes of convenience, can we agree that this covers both of those too?

screenfetch: Because all the cool kids are doing it

I got an e-mail a month or two ago from someone who preferred to remain anonymous, suggesting screenfetch for attention. I wish the e-mailer had allowed me to use their name, because screenfetch is worth crediting the tipster.


You’ve probably seen screenfetch (or something like it) at work in screenshots and Linux forums around the Web. It (or something like it) is a fixture in the screenshot threads in the Arch Forums, and I’ve seen it (or something like it) in r/unixporn more than once.

screenfetch does only what you see there: It lists the general information about your system in a way that might, conceivably, help someone build a similar desktop if they liked. Hence the notes on GTK themes, icon themes, fonts, and so forth.

screenfetch in particular has the option to take a screenshot automatically, provided you have some sort of screenshot tool installed — I believe the default is scrot. Others can be used, with a little nudging of screenfetch’s options.

screenfetch is not limited to Arch Linux and Openbox, and a full list of recognized distros, window managers and desktop environments is listed in the --help flag. It’s more than likely that yours is included.

I’ll leave off at this point, because as you might imagine, there is more than one way to get a nifty multicolor ASCII logo and system rundown on your screen. … πŸ˜‰

cpubars: More processors equals more fun

This is kind of a pointless screenshot for cpubars, given what it’s intended for:


If I had two cores, or maybe four, or maybe 16, or one of these, cpubars might really put on a show. As it is, my lowly non-hyperthreading P4 will only animate one row of CPU stress bars. More’s the pity. 😦

The home page says cpubars is intended for multicore machines accessed over ssh, and I do believe that cpubars could do just that. It wisely sticks to block characters and simple colors, which should cause minimal stress while offering a still-pleasing display.

After all, what good is a CPU monitor that puts the CPU to task while running? πŸ˜›

Aside from that, I don’t know there’s much to say about cpubars. The binary is 23K. There’s an option to set the refresh delay. I think that’s it.

Good enough — color, animation, low profile and a straightforward design. Huzzah, I say. πŸ™‚

forkstat: Catching the small and the quick

It seems to me that the author of forkstat and I have had a similar problem in the past: Sometimes there are small processes that spawn and end so quickly, it’s difficult to catch them on top or in another system tool.

So that’s when forkstat becomes useful.


forkstat is simple to control and runs smoothly. You can use flag options to set a run duration, modify the output a little, and ask for a summary of statistics. There is also a small option to filter for specific events.

I’ve already pinned down a couple of spawning-respawning processes that I am wondering if I should (or just could) prune back.

And so forkstat has already proven useful. πŸ™‚ If you need something to catch those really small, really fast processes that might be abusing your hospitality, forkstat is probably the man for the job.

recap: Everything about everything from everything, prepacked

I’ve cruised through enough system information tools over the past couple of years to recognize a few good ones and more than a few bad ones.

recap takes some of the better ones, mixes them together, and generates customizable reports.


That’s an example, where recap can pull in things like free, vmstat (think: procps), sar and a few other tools you might recognize off hand. Output goes to /var/log/recap/.

If I understand correctly, the author intended for recap to work at interval, along with something like cron. This makes sense, as a polling and logging tool that you can trace backward in time.

As a roundup of system data, recap makes good sense and has enough small customizable points to tweak that you can probably adjust it to your needs or wants.

I do feel obligated to mention though, that recap itself, for what I can see, is really only marshaling the efforts of outside tools, and consolidating their output. So it’s true, recap doesn’t seem to be doing any of the heavy lifting, but it does put together a nice summary.

And you might have a script already that does that for you. If not, chances are you could whip one up in a short amount of time.

On the other hand, recap seems to have done for you already. πŸ˜‰

procinfo and friends: Become one with your hardware

Sorry about the delay, some real-life issues demanded attention, and couldn’t be avoided. As a way of making up for the lost time, here’s a three-in-one hardware information tool: procinfo.

2014-08-29-6m47421-procinfo 2014-08-29-6m47421-lsdev 2014-08-29-6m47421-sockinfo

procinfo appears as procinfo-ng on the home page and in Arch Linux, but just procinfo in Debian. Both packages install three tools: procinfo itself, lsdev and sockinfo.

sockinfo is probably the leanest of the three; you can see its output above, and the Arch version doesn’t even have a man page. sockinfo isn’t a bad program, but there are probably some more helpful socket analysis gizmos out there, so I doubt sockinfo sees much action.

lsdev is a step up, but only by a tiny bit. This will really get you closer to your hardware, right down to the IRQ and DMA. According to the man page, lsdev has no options, so what you see is what you’ll get. Depending on your system, of course. πŸ™‚

That’s probably where my only complaint about lsdev arises: The output is a bit spattered. That might be a consequence of the hardware or the way the information is reported, but it’s difficult to see what is appearing in what column. Hopefully if I should ever need lsdev, I’ll have enough information at the start to intuitively pick apart lsdev‘s report.

procinfo is the real star of the show, and has enough options and visual style to make up for the shortcomings of either lsdev or sockinfo. Check out its man page, and then take it for a spin with procinfo -H -n2 or procinfo -H -n2 -d if you’re feeling crazy. You’ll get a nice, steady system-wide update that reflects the inner workings of your mysterious electronic doodad.

procinfo has a lot to tell and it’s worth trying for its meager footprint and clean encapsulation of everything from hard drives to memory usage. It doesn’t have color, but hey, you can’t have everything. If you did, where would you put it? πŸ˜‰

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. πŸ™„

ps: That other process tool

I spent way too much time talking about factor, so I’m going to clip ps short. Which probably isn’t fair, since ps has an actual measure of use, while factor was … just for fun.

Here’s what it does, when bidden:

kmandla@6m47421: ~$ ps
  PID TTY          TIME CMD
19982 pts/1    00:00:00 bash
19983 pts/1    00:00:00 ps

That seems a little sparse. Let’s look around for some better uses. How about …

kmandla@6m47421: ~$ ps -a
  PID TTY          TIME CMD
  189 tty1     00:00:00 startx
  206 tty1     00:00:00 xinit
  211 tty1     00:00:03 blackbox
  216 tty1     00:01:28 urxvtd
20000 pts/1    00:00:00 ps

Better. Let’s add “user format.”

kmandla@6m47421: ~$ ps -au
kmandla    184  0.0  0.0   5528  1572 tty1     Ss   07:09   0:00 -bash
kmandla    189  0.0  0.0   5464  1632 tty1     S+   07:09   0:00 /bin/sh /usr/bin/startx
kmandla    206  0.0  0.0   3812  1164 tty1     S+   07:09   0:00 xinit /home/kmandla/.xinitrc -- /etc/X11/xinit/xserverr
kmandla    211  0.0  0.2  12428  4336 tty1     S    07:09   0:03 blackbox
kmandla    216  0.2  0.6  24228 12936 tty1     S    07:09   1:28 urxvtd -q -o -f
kmandla   5778  0.1  0.3  11956  7644 pts/2    Ss+  13:00   0:13 vim
kmandla   8516  0.1  0.3  20804  6288 pts/0    Ss+  13:45   0:06 mocp
kmandla  19982  0.0  0.1   5516  3348 pts/1    Ss   15:20   0:00 bash
kmandla  20006  0.0  0.1   6148  2840 pts/1    R+   15:26   0:00 ps -au

And that’s probably where I’d stop. ps has a lot more options, but not all of them strike me as … practical, to be honest. Beyond a point, I start grepping through things like ps -A and ps -aux. But you can decide.

ps is in procps in Debian and procps-ng in Arch. And probably in something similar in your system. πŸ˜‰