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. 🙂
Quick on the heels of tree and ddir, a loyal reader pointed out ncdt, which takes the tree model and adds a small feature or two.
As you can see, ncdt adds the size of files and directories as part of its default display. So in situations where it’s useful to see directory structure and size — such as labeling removable media, like CDs — it is probably more useful.
Unfortunately, I see no options to adjust what ncdt shows, so there are no “human-readable” (which I prefer) output flags or the like. What you see is what you get.
ncdt also promises to show “special” data for mp3 files, but the Debian version as well as the version I built on my Arch system from the Debian source package showed nothing. Even the sample screenshot in Debian doesn’t show anything “special” for mp3 files. Hmmm. 😦
It’s possible that there is an added dependency that I don’t have, or perhaps the mp3 files I tried post-date what ncdt is capable of analyzing. I checked the ReadMe and source files, but I got no hints. And the only home page I have for ncdt is the Debian package page above.
No matter. ncdt adds a little to the tree model and could probably, at one time in the past, show a little information about mp3 files. It’s an interesting evolution, even if it still needs some attention to reach fruition.
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. 😉
For a small tool that doesn’t do much, notifyme has a lot of potential. It’s a little tough to show it in action, but I’ll try to narrate the steps.
Starting notifyme doesn’t do much except show a few stats on recent logins for the target account. When the user logs in again though, or opens a terminal emulator under the same name, you get a message in the upper right corner of the screen. That’s what you see on the left.
On logout, you get another message, and that’s what you see on the right. The benefit of this over conventional tools — or more replete utilities like whowatch — is in its stealth approach: Unless there’s a login or logout, there’s no need for notifyme to take up your time.
And it’s also a lot more convenient than trying to keep an eye on an entire different application, waiting for your favorite misbehaver to show up. Of course, once your bad guy is logged in, you will probably want to shift to something like whowatch, for more information.
notifyme is in Debian, but only Squeeze and Sid that I saw. I transplanted the .deb file into Mint without a problem, which says to me it could find its way into any other Debian-based system, within reason. I didn’t see it in Arch.
I will admit on a single-user, quasi-desktop system like I use, notifyme has almost no practical use. After all, I know when I’ve logged in. 😛 On a larger system with more activity though, this strikes me as particularly useful.
I can see the usefulness of genstats almost immediately. Given a text file, you can pull out a frequency report with very little effort.
And since genstats handles its input and output in much the same way as cut, you should be able to get the information you want within just a few minutes of compiling it.
It may not be appealing to you to track word frequency in a flat text file, but consider what you could do with genstats and your average log file. That is the author’s suggestion, and the screenshot on the home page gives a good example of some advanced genstats usage.
My only complaint about genstats is so trivial that I’m embarrassed to mention it. In a file with 12 lines, and with four of the words in the second field being the same, the display should read “33%,” not “0.33%.” The latter is a third of a percent, while the former is a third of the whole. Or perhaps there is another calculation at work there, that I’m not sure about.
I get the picture though. And having said that, I suppose it’s worth mentioning that gentstats doesn’t give you a lot of control over the output. As best I can tell, that is the only style of report you’ll see from genstats.
genstats appears to be a free-roaming program; it’s not in Arch/AUR or Debian. So if you want something quick and easy to package, this might be one. 😉
When I first read the description for httping I took it to be a ping tool intended specifically for HTTP addresses. I couldn’t really see how that would be terribly different from plain old ping, since I’m in the habit of just feeding URLs to ping anyway.
Oh, but this is something even better than that. httping has a lovely ncurses mode that shows all kinds of flashy, splashy, dashy color and metrics. And manages to cram it all into one small display.
I have a lot of the fancier effects turned on there; if you install the FFTW libraries from your distro (fftw in Arch; probably something from here in Debian) you can play with the phase meter and traffic history bars too.
Or turn all that off and get just the plain ncurses display. Or just feed it an address with no flags, and get something a lot like straight ping. But where’s the fun in that? 😉
You could make the argument that pressing the phase display and the history graphs directly over the displayed text makes things hard to read, and I’d probably have to agree for the most part. However, I don’t remember too many other ping tools — or other network monitors, for that matter — that tried that, except perhaps for the venerable iftop, or its offshoot iftopcolor.
But personally, I like it. I think it works, and you have the option to remove it. httping is different, it’s colorful, it approaches a specific case and handles it completely but adroitly.
An easy decision: One gold star for httping: ⭐ Don’t spend it all in one place. 😉
I’m suddenly inundated with testing a half-dozen new laptops here, so I don’t have a lot of time for writing up posts.
I did have a moment this morning to check out spew, which I believe is in the Debian repos, in Fedora and in their derivatives, but surprisingly not in Arch.
spew is a tool for testing I/O performance and generating workloads for those tests. What you see above is spew’s text-based interface, writing out a quick 128Mb file and checking the read-write stats.
By default spew works mostly in a CLI-fashion, as opposed to the whole-screen approach you see above. We haven’t seen too many I/O tools for the console — not counting iotop, which was the first one I could think of offhand — so it’s probably a good idea to keep this one around.
The next time I get an ancient laptop and a wicked-slow hard drive, I’m going to hunt down spew and see what it can tell me. Next time. 😉