since: Since you last checked

I promised I would get since onto these pages before the end comes, mostly because I don’t remember any other log viewer that has this behavior by default … and I want to be able to remember it in the future.

It’s hard for me to be sure though, after so many years and so many log utilities.

since seems different because, as you might have inferred from the screenshot, it only displays log data since the last time it checked. So you can see the last portions of pacman.log at the top of that image, then the repository update. The next invocation of since only shows the two lines that had been added.

I’m sure other tail-esque tools can do this, and possibly add a few nifty tricks in passing. It’s just a matter of finding the right flags and getting them in order.

For its own part, since keeps its state file in ~/.since, and you have the option to ignore it. You can also tell since to use a special state file, to run periodically, to ignore compressed logs, ignore missing logs, and a lot of other options.

I am not a real bloodhound when it comes to keeping an eye on logs, so at its best, since is useful … but only rarely. On my pseudo-desktop system, there’s almost no call for it.

On a more complex system or in a situation where log files are critical, it might save you some time trying to get the information you need. I’m willing to give it a thumbs-up. 🙂

rmlint: The potential to purge

I am behind the power curve today, because of some real-life obligations. I am going to grab something quick and easy so as not to fall behind; things are going to be even busier into the weekend.

This is a snapshot of rmlint in action:

rmlint cruises through your directory tree, and offers to remove files it thinks are duplicates, zero-byte or hollow folders. And as you can see, given enough space, it will take its time to come up with a menu of potential excisions.

I did say “offers,” which is an important distinction. rmlint’s output is a little unexpected: By default it generates a script that will remove suspicious targets, but doesn’t outright eliminate them.

Which is a good thing; it means you have the option to adjust its list, and it also means you take the next step — running the script — with conscious aforethought. You can’t blame rmlint for whacking apart your /usr/lib folder if you told it specifically to do it.

I like rmlint for a number of reasons — it’s rare that I see a system cleaner, it takes the safe route by creating the script, and it has a smidgen of color.

But that’s about all the time I have today; I’ll get deeper into something tomorrow … I promise. 😉

logintop10: Drum roll, please …

Here’s another one that will probably be more interesting to administrators or multi-user system fans: logintop10.

It should be fairly obvious what’s happening there: logintop10 parses through your wtmp file (which was at /var/log/wtmp on my Arch system) and comes back with an array of login statistics. Output is to an HTML file of your choosing, with very clean formatting and with a little color here and there.

As far as I can see, there’s no way to adjust the exact output that logintop10 shows, unless you’re willing to manhandle the results. There is an option to “dump raw data,” but that really only adds on a full list of logins to the output page. If you’re on a big system that would create a file of considerable length, so I can see why it’s not enabled by default.

Either way, wtmp is in a binary format that will require some sort of tool to read, so logintop10 is doing you a favor and sifting through the data file, then arranging it in a prettified fashion.

logintop10 comes from the same author as genstats, and so perhaps the two might be useful in tandem.

In AUR, but not in Debian. There is a prebuilt .deb file on the home page though. 😉

whowatch: Don’t just take my word for it

In the wake of wpe and we yesterday, I thought for sure today’s program would seem dull by comparison. After all, wpe more or less walked away with all the judges’ accolades, and without batting an eye.

But not to be outdone, here’s whowatch:

Different area, but no less panache. whowatch takes on the task of monitoring logged-in users, and showing what they are up to. And it does it with considerable finesse.

The default display is rather mundane, with just the who-esque list of users logged on to your system. But asking for the tree display, or listing ownership, or focusing only on one user’s activity gives you new displays, each with their own set of submenus and details. And suddenly whowatch is a gold mine.

whowatch doesn’t stop there though, with system information and load averages as part of its default display. So you could, conceivably, rely on whowatch as your system monitor as well. Not that there aren’t plenty of lightweight monitors out there to supplement whowatch, but it’s still a nice touch.

Admittedly whowatch is of very little use to me, as most of its power is probably uninteresting to single-user system. But whowatch would be particularly useful on systems that accept remote logins or accommodate multiple users. I also noticed that whowatch is clever enough to break down multiplexer sessions, so things like screen are listed as multiple entries for each pane. And from there, the details continue.

And given that there’s a control-key combination to kill a process — CTRL+K, which just sounds satisfying 👿 — it might be useful to keep whowatch installed if you’re an administrator.

whowatch is in both Debian and Arch, and it’s easy to see why. whowatch is part of Arch’s Community repo, which is sort of like an offhand endorsement by Arch that a program is really that good. So don’t just take my word for it. 😉

This is well deserving of a gold star: ⭐ Wow, two days and two stars. Is this a trend … ?!

gdisk: A familiar face

I’ll try to keep this one quick; I am already short on time this weekend because of personal obligations. But I also think gdisk is something that resembles fdisk enough (and even perhaps cfdisk and some other partition tools) that mentioning it at all is a rehash of sorts.

Anyway, feast thine eyes:

gdisk, for what I have seen, just about matches fdisk keypress for keypress, with the major difference being its relative comfort in working with the newer generation of hard drives that use GUID partition tables and not MBR style.

Wikipedia tells me the changeover took place sometime around 2009, and so it doesn’t surprise me that I use it so rarely. The newest, most powerful machine I have in the house right now is 8 years old, and I’m wondering if it isn’t time for me to upgrade that. …

I wouldn’t want to fall behind on the times, now would I? 🙄

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

logtop: Kind of like a *top … for a logs

I’m not a log nut. I mean, I don’t spend hours poring over logs to try and find the source of my angst (I’m not a terribly angsty person though).

I do know that’s a favorite hobby for some people and professions, and to that end, logtop may be exciting.

logtop is kind of like a *top, if it makes sense to watch a log continually for updates and changes. And as the author suggests, using logtop in this sense

tail -f /var/log/pacman.log | ./logtop

is much the same as doing this

watch 'tail /var/log/pacman.log | sort | uniq -c | sort -gr'

Bt you could say that equating logtop to that line means it’s not adding much to the classic black-and-white Unixy tools you probably already have.

And given that tail already has an -F flag for following log updates, it might not seem like logtop is actually an improvement.

My example doesn’t do much justice to logtop though, since it is prepared to handle much heavier and more dense log updates, as might happen with machines more powerful and active than my puny Pentium 4.

And given that logtop is prepared to calculate and show line rate stats and contort its output to follow specific formats, I’d be doing a great disservice to logtop by dismissing it out of hand.

But I’m not the best judge of these things, since I already confessed that watching logs was something I do rarely at best. Those of you who find solace or salary in staring at logs … you are the target demographic here. 😉

dothost and lddot: Looking good, feeling fine

Well, after a day or two of completely scrambling my scheduled posts — and even revisiting an application that I had already mentioned a year ago 😳 — I have some catching up to do.

Please accept this as a double post, and hopefully make up for a little lost ground. Here’s lddot and dothost, respectively, both from Jakub Wilk and both in AUR (but not in Debian).

 

Just because you prefer a text-based lifestyle doesn’t mean you can’t be a visual learner. dothost and lddot both cater to that, by generating neatly arranged flowcharts with the help of Graphviz and perl-graph-easy.

By themselves, the output is strictly textual, so if you can’t get access to either of those ancillary programs, you won’t get all the pretties you see above. And it should go without saying that some of the more complex arrangements are going to require extensive screen real estate. Don’t expect them to squish everything into 80×24.

I suppose you could argue that neither offers much information that isn’t available through ordinary ldd-ish or traceroute-ish tools.

And judging by their help flags, neither tool is particularly flexible or extensive, beyond generating the plain text output required by the next program in line. So if you’re looking for something with a thousand tweaks all accessible by CLI flags and XML conf files … these probably aren’t it.

But you gotta admit: They’re looking good. 😉

xrestop: The irony is palpable

I am not surprised that there is a top-like tool for monitoring the X Window system. After all, there is a plethora of *top tools aimed at any aspect of your hardware or information flow, and X is not that special.

On the other hand, the fact that xrestop is intended to run in a console is ironic at the least.

I know it works, but I also think that most any text-based tool works smoother than something running under X, the slug. That’s just my generalized opinion, and I’m not bashful about it.

But a text-based tool that gives readouts on X system demands is far too ironic to leave alone.

xrestop itself is not in any way disappointing or flawed — in fact, it does a great job showing what is running, what is taking up time and what is most demanding on any particular display. It can accept specific display addresses and report on those, adjust its refresh delay and a few other options through command flags.

All in all, it’s at least as good as some of the other top-esque tools that are out there, aimed at other aspects of your computing experience.

Still … I would have expected something … well, graphical. After all, doesn’t a graphical load monitor aimed at the graphical subsystem just … make sense? 😕 Maybe not.

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