Tag Archives: system

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.

2015-04-26-6m47421-since

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:

2015-04-23-l3-b7175-rmlint

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. ๐Ÿ˜‰

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:

2014-01-11-l3-b7175-gdisk

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.

2014-12-26-jsgqk71-ips

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.

2014-12-24-jsgqk71-logtop

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. ๐Ÿ˜‰