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. 😐

smartmontools: A hard drive’s best friend

Here’s something you don’t see every day:

 

I mentioned a short while ago that I bought this hard drive to run in a Dell Inspiron 8000 more than eight years ago, and those screenshots are proof.

The actual conversion is up for debate, but a power-on time of 18,562 hours works out to be more than two years of working time. And it keeps on ticking. 😀

I know these things because smartmontools tells me. The suite provides a rundown on the S.M.A.R.T. data from a hard drive, then breaks apart the analysis into something vaguely human-readable.

How you interpret the information is up to you, but the beauty of it is that, as I understand it, it’s sometimes possible to get a warning that a drive is about to die.

And as someone who has heard deathly clacking noises from hard drives, any kind of warning would be a good thing. 😯

I must admit I’ve never tried to use smartmontools with either an SSD or any kind of surrogate, nonmechanical drive. It would be interesting to see though.

While it’s not a complete diagnostic tool and not a data recovery utility, it’s worth remembering that the information is available to you. Mark, and remember. 😉

P.S., yes, I know 18,562 hours qualifies as Old_Age according to smartctl, and I should have shown that a lot of other categories are marked Pre_Fail. Don’t worry, I have planned accordingly. 😉

lsblk, lshw, lsmod, lspci: Hardware, up close and personal

I’m out of order again, but I can write this while offline and copy it into the browser for minimal network stress. Here’s lsblk, lshw, lsmod and lspci, from left to right.

   

All of these fell within the L section and all have relatively the same function — show what hardware is present, and how the system communicates with it. Strictly speaking, these are troubleshooting tools and as far as I know they don’t harbor any easter eggs.

lsblk — list block devices — tells you drives and similar hardware that are plugged in, their partitions, and where they fall in your system. lsblk is bundled with util-linux.

lshw — list hardware — can give you a rundown of the hardware detected in your system, which is always helpful. In some distros, like Arch, it is not installed by default.

lsmod, list modules, shows modules inserted in response to the hardware profile, or your demands. My example up there is sorted, just for readability.

Finally lspci, which lists PCI devices, and if you ask nicely, the modules that are/were needed to run them. By default lspci is a little more terse; the screenshot shows it with a triple v flag for maximum detail.

Any one of these can give you the information you might need, and each one has their own slant on hardware detail. If you’re a fellow hardware junkie or if you need to pin down a particular problem without the need of graphics, this is what I would suggest. 😉

Bonus! lsusb, which shows USB devices present in the system!

Wow! The fun never ends!

Double bonus! lshw has a graphical interface!

The fun really never does end! 😯 😐

hwclock: Keeping time with you

I wasn’t going to include hwclock because I assumed there wasn’t much here to explain or show. That’s partly true.

But hwclock has, in the past, been a crucial tool for keeping out-of-date machines on time, literally.

These days that’s not so much a problem for me; my oldest machine is a single core beast, but it still has more than enough oomph to avoid clock slippage.

Such was not always the case, particularly as hardware drifts back over the past 10 or 15 years. I’ve had machines with weak CMOS batteries that needed regular updating, or machines that would lose their bead on time if the workload got too heavy.

In those cases, a combination of ntpdate and hwclock usually did the trick (yes, I know ntpdate is technically deprecated).

And to be honest, I still use those two from time to time, to correct time to time (puns intended). ntpdate syncs, hwclock with the -w flag writes it out to the hardware.

There’s more that hwclock can do and if you build systems from almost nothing, it becomes important that you know how to use it. As it is though, I’ve already said too much about very little, and I know your time is valuable. 😉

One last toy before the H section is finished. Amazing. … 😯

P.S., hwclock is in util-linux, depending on your distro.

ethtool: What doesn’t it do?

I failed in the snarky headline department today, when I ran face-first into the brick wall that is ethtool.

Fact is, I can’t think of much to tell about ethtool that doesn’t grossly under-represent its ability. Or for that matter, over-represent my understanding of it.

Just the help flags alone should be enough proof that ethtool does stuff other utilities just don’t stack up to.

You want a rolling status with transfer info? ethtool scoffs at your paltry request.

You want an animated graph showing line speed? ethtool does not debase itself with such frippery.

You want cumulative transfer totals with a web interface and a console backend? Look on my works, ye Mighty, and despair!

Don’t idle with ethtool. Don’t approach it on trivialities. ethtool is not to be bartered with, and is not amused by your foolish antics. ethtool is dangerous. ethtool is the bandit that eats children and old people. ethtool is mors ab alto. Look quickly over your left shoulder, and maybe you will see ethtool.

I may never be able to answer the question, “What doesn’t it do?” Some questions should just stay unanswered. 😯

dmidecode: Due diligence

In case you hadn’t noticed, or in case it wasn’t obvious, I am getting close to the end of the D section, and drifting into software I have no business installing.

Not that these things are somehow verboten, they’re just esoteric or for an explicit group of people, or beyond the reach of casual newbs like me. (And yes, I consider myself a newb. Always have, always will.)

But in an effort to be fair to software that’s working and available, I’m mentioning it out loud here. Maybe it will never crop up again in my lifetime, or maybe it will be crucial down the road somewhere. Or for someone else out in the world.

All that being said, here’s dmidecode.

I understand in general and primitive terms that dmidecode and its sister tools read BIOS information and display it at the terminal. That much is clear just from the man page.

But I couldn’t tell you, even at gunpoint, how information like that would be useful except to people who work with the very core of GNU/Linux, perhaps writing drivers or building … kernel … stuff. 😐

Like I said, in a lot of things I’m a newb. dmidecode is available and works perfectly on my hardware, which might mean that I am lucky.

If information like that is useful to you, or if you find dmidecode to be a worthwhile addition to your software suite, please enjoy. I consider these last few posts to just be due diligence. 😉

Bonus: D is for Debian

About six months ago I scoured an ancient Debian package-a-day web site for all its fruit (with bew, if you must know), and came up with a long list of applications … some text-only, some graphical.

The graphical stuff has been going to the Package of the Day subreddit, and the rest I kept for future reference.

One side effect of that scouring (not necessarily good or bad) was that there was a huge crop of Debian-specific stuff. And of course, almost all of it starts with D.

So here’s a quick rundown on a few things that you can take advantage of, but really only if you’re using Debian or a derivative.

• alien: Like deb2targz, which I just mentioned, alien will convert .deb packages to tar.gz format.
  
  

  It will though, also convert to rpm, slp, LSB and even Solaris format. It can patch on-the-fly, incorporate scripts into packages and a lot more. deb2targz is good, but if you use Debian anyway, you should probably grab alien instead.

• debian-goodies: dpkg, aptitude, apt-cache and apt-get always satisfied almost every need I had in Debian, but debian-goodies adds a lot more tools to the mix.
  
  

  Some of the coolest? debget, which bypasses aptitude and company to yank just a package off the repository. And dpigs, which shows which packages are hogging space. 😉

• dh-make-perl: I know next to nothing about perl or Debian packaging, but if I understand the description correctly, this should be a help with both.
  
  

  I leave it to you to pick up the torch on that one.

• deborphan: deborphan has been around forever, and it’s one of the first things I used to install whenever I worked with either Debian or Ubuntu.
  
  

  deborphan skillfully skims through lost or detached packages on your system and lists them as orphans. It makes it quite easy to recover space after a mess of installations, or to check for leftover crud. (By the way, Arch users have something similar in pacman -Qqtd … you’re welcome. 😉 )

• dlocate: Again, if I understand the description and the help flags, dlocate amplifies some of the search functions of dpkg.
  
  

  It’s more than just a replacement for dpkg -S though, as you can see above. Check the help flag; it’s got a ton of features.

• discover-config: I have this on my list as a hardware check system, but it seems unwieldy and I’m not sure if it’s meant to be used beyond boot scripts.
  
  

  It works sure enough, but I might just be mishandling it. The package page and man pages might give more information.

• dwww: I’ll mention just one more, and I don’t have a screenshot because I couldn’t figure out how to get it working. dwww, as all the program descriptions and man pages suggest, allows you to peruse documentation with a browser. I tried for a little bit but got no love from it. If there is a howto out there for setting it up, send me a link. I’m curious.

That’s enough from the Debian pond now. If you’re not a Debian fan, you probably found this excruciating to start with, but if you have any swirly in your bloodstream you might find something fun to mess with there.

We now return you to your regularly scheduled blog. 😉

Test bed: Dell Latitude D600

Because life isn’t interesting enough, last week I pinned down a used computer and brought it home.

That is a plain-Jane Dell Latitude D600, with not a bell or whistle to brag about. Jane came into the house along with an assortment of leftover PCMCIA wireless cards, a docking station that may or may not work with this model, a power cord and an excellent lesson in the power of patiently bargaining over three or four days.

And in return, I parted with the rough equivalent of US$50.

This is 4dkln41 — a 400 MHz-bus Pentium M, 1.6Ghz, with a lowly 512Mb of memory, Intel Pro/Wireless 2100 and an ATI Mobility FireGL 9000 on a 1400×1050 LCD. This machine reminds me a lot of the Insprion 8000 I kept for many years, in that it’s roughly the same size and shape, same era, and similar hardware.

It’s a bit scratched, not too purty, but 100 percent working in all the places that matter — keyboard, screen, audio, optical drive, power train, etc.

It came with some disadvantages in life, most notably that this particular machine is one of the rare ones that can’t handle PAE.

Up until now, PAE was just another acronym I had to run to Wikipedia to figure out. I hadn’t ever seen a machine that spat out errors about PAE.

Those three little letters turned out to be very important though. Linux Mint outright refused to boot, as did a couple of other smaller distros — all because of PAE. 😦

Arch, on the other hand, didn’t seem to care. But installing Arch on it came with its own set of headaches.

Most notably, absolutely hideous video performance. Some of the worst I’ve ever seen. Arch’s xf86 radeon driver was giving me redraws in IceWM that I could actually watch trace along the screen, and slowly fill with data.

It was painful. Honestly, I’ve seen K6-2’s with better redraw rates than that.

The vesa driver was about the same. I tried to build the catalyst driver, but my efforts were fruitless. The wiki instructions failed miserably. In desperation I even plugged in a few third-party repos and backdated versions of xorg-xserver. But things were either the same — or worse.

This couldn’t be the case, I thought. It can’t be that this machine is doomed to such lousy performance. Perhaps there is a mechanical issue, I thought.

As a troubleshooting measure (I swear) I installed Windows XP. Dell’s support site archives all the appropriate drivers, and the proprietary ATI Catalyst package for XP was marvelous.

Instantaneous performance. No wicked laggy redraws. Full 3D acceleration. Video modes from 1400×1050 to 800×600, no sweat. So at least I knew it wasn’t hardware-related.

Of course I have no love — or need — for Windows, but the future of the machine was bleak without some sort of proper distro on there. I briefly thought of running an XP system with only free applications on it. And quickly moved on from that idea.

I also contemplated just running a framebuffer system, but it was a bit disapppointing after watching Windows spin through Deus Ex (best game ever) at full detail and full resolution. And even Arch’s radeonfb environment was sluggish.

So for a short while it looked like Windows or nothing. A bad situation, to say the least. 😦

On one last hunch, I decided to try Debian. If the main limiting factor was PAE, then possibly one of Debian’s versions would sidestep that issue.

And Debian’s always been the go-to distro in my times of direst need. Maybe this time it would be successful.

To make an already too long story short, Debian’s i386 version installed without harassing me about PAE. It put a picture-perfect graphical desktop in place, and best of all, performance was magnificent.

Almost as good, if not on par, with Windows. No draggy desktops, no slow filling of application windows. Full screen h264 video (no 1080p, of course). It was bewildering.

And Debian on that machine runs like a cat on fire. Insane start speed. Faster than Arch. Faster than the dual core. Faster than the dual core with Arch. 😯

X pops into place like it’s jacked up on sugar. And as you can see in the screenshot, much of my same grotesque old pretend-Windows XP Classic theme translates directly to Debian.

True, I have to manhandle the fonts a little, but it works. And 3D acceleration is still a bit fuzzy. As in, I haven’t really tried yet.

Overall, this is more than just a bit of a shock. With so many failings — either hideous video performance under Arch, or refusing to even start because of PAE in three or four other distros — for Debian to punch a hole through and come out shining on the other side … well, it’s a Christmas miracle. Or something like that. 😉

P.S.: The guts? Here you are. PDF alert.

Test bed: Acer Aspire V5-122P

My intercontinental transition is more or less complete, and with a new home comes a new array of toys.

For the last week or so I’ve been using a home-grade lightweight department store PC as a test bed. This is an Acer Aspire V5-122P.

It’s been a long time since I bought a new computer, and ordinarily I would be averse to it.

I was losing time though, and had no local connections for leftover hardware, and this had the right price on it.

Guts are:

System:    Host: v5-122p Kernel: 3.8.0-19-generic i686 (32 bit, gcc: 4.7.3) Distro: Linux Mint 15 Olivia
Machine:   Mobo: Acer model: Aspire V5-122P version: V2.04 Bios: Insyde version: V2.04 date: 05/10/2013
CPU:       Dual core AMD A4-1250 APU with Radeon HD Graphics (-MCP-) cache: 2048 KB 
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 3992.46 
           Clock Speeds: 1: 1000.00 MHz 2: 1000.00 MHz
Graphics:  Card: Advanced Micro Devices [AMD] nee ATI Kabini [Radeon HD 8210] bus-ID: 00:01.0 
           X.Org: 1.13.3 drivers: ati (unloaded: fbdev,radeon) FAILED: vesa Resolution: 1368x768@0.0hz 
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits) GLX Version: 2.1 Mesa 9.1.3 Direct Rendering: Yes
Audio:     Card-1: Advanced Micro Devices [AMD] FCH Azalia Controller driver: snd_hda_intel bus-ID: 00:14.2
           Card-2: Advanced Micro Devices [AMD] nee ATI Device 9840 driver: snd_hda_intel bus-ID: 00:01.1
           Sound: Advanced Linux Sound Architecture ver: k3.8.0-19-generic
Network:   Card: Atheros AR9565 Wireless Network Adapter driver: ath9k bus-ID: 01:00.0
           IF: wlan3 state: up mac: 00:1d:76:c3:bc:5c
Drives:    HDD Total Size: 500.1GB (42.0% used) 1: id: /dev/sda model: ST500LT012 size: 500.1GB 
           Optical: No optical drives detected.
Info:      Processes: 167 Uptime: 1 day Memory: 542.8/3475.2MB Runlevel: 2 Gcc sys: 4.7.3 Client: Shell inxi: 1.8.4 

My personal opinions are sometimes one way, and sometimes the other.

It’s got terrific battery life, which is not something I’m used to. It’s very light and has a strong display, which are also things I’m not used to.

And I can honestly say this is the first computer I’ve ever had with a touchscreen.

On the other hand, I am used to machines that run me US$20 or so at the max. This was a good deal more than that, even if it was a bargain-basement price.

But I can hardly complain. This is running Linux Mint 15 (as you might have noticed) without effort, setting up perfectly and with no complications save a failure to properly turn off. No biggie.

(It did come with that abortion of an operating system, Windows 8, preinstalled. The salesperson was horrified when I told him I planned to put Linux on it. And he ran away mad when I told him Win8 was unilaterally despised. 😈 )

My plans include a shift to Arch and a different window manager to be sure. Mint with MATE is a little laggy on this.

After that, probably drop back to console applications. And there you have it.

Test bed: Gateway Solo 2150

Here’s the test machine du jour in action.

System: Host: solo-2150 Kernel: 3.6.8-1-ARCH i686 (32 bit, gcc: 4.7.2) Console: tty 10 Distro: Arch Linux
Machine: Mobo: Gateway model: Solo 2150 version: Rev 1.0 Bios: Gateway version: 17.50 date: 01/21/2000
CPU: Single core Celeron (Coppermine) (-UP-) cache: 128 KB flags: (sse) bmips: 1002.05 clocked at 501.145 MHz
Graphics: Card: Advanced Micro Devices [AMD] nee ATI Rage Mobility P/M AGP 2x bus-ID: 01:00.0 chip-ID: 1002:4c4d
X-Vendor: N/A driver: tty size: 146x26 Advanced Data: N/A out of X
Audio: Card: Creative Labs Ectiva EV1938 driver: snd_ens1371 ports: 10c0 1080 bus-ID: 00:09.0 chip-ID: 1102:8938
Sound: Advanced Linux Sound Architecture ver: 1.0.25
WAN IP: None Detected! IF: eth0 ip: 192.168.0.4 ip-v6: fe80::2a0:b0ff:fe2c:631d
Drives: HDD Total Size: 12.1GB (33.1% used)
1: id: /dev/sda model: TOSHIBA_MK1214GA size: 12.1GB serial: 60C95063T
Optical: /dev/sr0 model: N/A rev: N/A dev-links: cdrom
Features: speed: 24x multisession: yes audio: yes dvd: yes rw: none state: N/A
Partition: ID: / size: 7.6G used: 1.4G (18%) fs: ext2 dev: /dev/sda3
ID: /home size: 3.3G used: 2.4G (74%) fs: ext2 dev: /dev/sda4
ID: /boot size: 92M used: 29M (32%) fs: ext2 dev: /dev/sda1
ID: swap-1 size: 0.25GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
Unmounted: ID: /dev/sr0 size: 1.07G label: N/A uuid: N/A
ID: /dev/fd0 size: 0.00G label: N/A uuid: N/A
Info: Processes: 69 Uptime: 4:00 Memory: 56.4/277.9MB Runlevel: 5 Gcc sys: 4.7.2 Client: Shell (bash) inxi: 1.8.23

That’s the insides. But the outsides are another reason I picked it out, for a lowly $15 (plus or minus). The physical condition is impeccable, with no scratches and only a few odd spots of grime that washed away without any effort.

Nothing is perfect though. There are a few shortcomings, some of which are internal and problematic.

For one, there seems to be some inconsistencies between the Rage Mobility card, and the available drivers for mach64-based cards. I put Xorg et al. in place, but the available drivers — and a few that were self-built — worked only in part.

Closest was a working desktop that started up fine, but crashed back to the terminal as soon as any graphic element moved … like the mouse pointer. 😐

Apparently this BIOS also has problems too. The kernel spits out a warning message on every boot, about ACPI errors that can’t be worked around. That also alienates the built-in network jack and USB hub. Neither one can be detected by the kernel, and don’t respond to my efforts to prod them. (Note, 2013-01-31: the USB and ports were restored with an obscure BIOS setting; the network plug may have life in it but the kernel can’t sense it and I find no documentation or drivers to reveal its innards.)

All of those things can be comfortably worked around though, and with no major heartache. I have plenty of leftover PCMCIA network and USB cards, some of which accrued even when I thought I was out of the ancient laptop game.

And videowise, there’s little I could expect to do with a Rage Mobility that isn’t just as accessible through the framebuffer or just the vesa driver. So I lose a meager shred of 3D acceleration? Oh well.

Best of all? Well, best of all … I can’t say that it’s fanless, but I have yet to hear it turn on. Many times I’ve wished back to the late 1990s for a computer that could run silent. This might be as close as I get. 🙂