Main navigation

New releases: Consolation 1.0b4, LockRattler 3.2, KeychainCheck 1.1

Here are three new releases of my free utilities for macOS Sierra 10.12.

LockRattler 3.2 has been updated to show the correct version number, and has gained its own app icon at last. It should still work exactly the same as the previous release.

KeychainCheck 1.1 has also been updated to show the correct version number, and has gained its own app icon at last. It should still work exactly the same as the previous release.

Consolation 1.0b4 also gains proper version numbers, and its own icon. It has several functional improvements which should bring it closer to a final release. These improvements include:

The app window can now be resized to change the size of the bottom text panel, into which log excerpts are placed. This allows you to enlarge the window to accommodate full lines in the log, and to view more entries at the same time. All the other controls remain fixed, though. When you quit the app, its window size and position should be remembered, and used the next time that you open it.

Any text entered in the upper other text box is now divided into arguments when you run the command, if the other text radio button is selected. However, each space in the text entered is assumed to be a separator between arguments. If you wish to use this, use the Show command button to check that the arguments will be separated correctly, or you may get an error. (I have fixed another bug in this in 1.0b4.)

Similarly, any text entered in the lower other text box is now divided into arguments at each space in the text. The most likely use for this is when wanting to add options such as --source and --debug. If you enter both of those into the text box, they will now be parsed correctly into separate arguments. Again, if in doubt, use the Show command button to check. (I have fixed another bug in this in 1.0b4.)

The manual has been updated to reflect these improvements.

I have added the word or to the Period section to make it clearer that you can either use the Period figure set at the left of that line, or the Start and End dates, not a mixture of both.

As far as I am aware, this is an error in TM handling its GUI. Specifically, I think it’s an issue in it connecting with the symbol in the menu bar. I do not read it as a problem with the backup process or the backups.
I have had it here on every backup since about El Capitan 10.11.3.
Howard.

Working fine here and it’s nice to have the text panel resizable. Also the “or” word does make it more intuitive.

If I may suggest further improvements, here are some ideas:

– ability to view the log output in full screen (or just in a separate big window)
– because the backend doesn’t work well with the Period (as you noted a few posts ago), it would help if it was at 0 by default
– a sane default for the Start time would be 1 hour before the current time, I think
– The 2 “other text” input fields are a bit confusing – maybe they can be named more precisely to indicate their function?
– ability to save and load settings to/from a config file
– ability to have more than 2 (ideally as many as one wishes) filters. Probably this won’t fit into the main window, so maybe an optional popup window with a button.

Thank you.
I have 1.0b5 on the go at the moment and it should be ready in the morning. Some comments:
– full screen works anyway, and you only lose a small amount with the controls, which I think should stay with the output;
– setting a period of 0 as a default is bad news for the majority of users, who want to check Time Machine entries (only). I tried this for a while in LogLogger, and it drove me crackers, let alone those users! Period actually works well over longer periods, but it isn’t so good on short ones;
– you really don’t want 1 hour of all log entries – the default should protect you from getting millions of entries!
– tooltips are coming;
– both the ‘other text’ boxes are unlikely to be used by anyone; however, without them you cannot do anything beyond the narrow settings offered, e.g. –debug.
– I have been thinking about a Preferences file, but actually between uses there is very little you want to persist. What I am going to look at is saving your last text predicates, which would I think be helpful.
– I’ve never yet found a use for more then 2 predicates, but I’d be fascinated to know of one.
Anyway, I think tomorrow’s release should be close to version 1.0. Thank you for using it and testing.
Howard.

Maybe the way I want to use the app is different from how most users will. The reason to request multiple filters/predicates is I want to see general useful log entries for a given system while eliminating useless/spamming ones (tens of thousands of them). This is useful for general system diagnostics, as opposed to troubleshooting a specific issue. As far as I understand, this is impossible to do in Sierra in any other way than this. (well, there are other means to do diagnosis but nothing to replace a proper system log).

A configuration file would help me to have the app started up with the defaults and filters I want, without the need to reconfigure it every time. Since software issues need to be diagnosed in the context of the system, and because I deal with many computers, not one, saving the settings into user’s library won’t cut it for me. Maybe this could be useful if there was a way to load logs from an offline system (i.e. from an attached storage device).

If you are not into developing a multi-purpose log reader, I am still grateful for what you’ve done so far. Just wanted to let you know what I am interested in.

Thanks.
I’d still be fascinated to learn of a useful 3-element predicate – having used the log show command, LogLogger, and now Consolation a great deal, even 2-element predicates are fairly unusual IME.
I’ll certainly put a config file on the wish list. However, my main purpose in this 1.0 release is to provide a tool which is comparable to what we used to have in Console before Sierra. That provides a starting point, and we’ll see how use evolves from there.
Try the beta tomorrow and see what you think. I’m always open to suggestions, but no one’s paying me to develop this!
Howard.

Of course, Howard, as mentioned, I am grateful for what there is and don’t have any expectations. Currently AFAIK your app is the only one to even approach the problem, and I am happy to have found it. Just figured you would appreciate feedback from someone who is actually planning to use it.

As to multiple predicates, the idea would be to use them as filters. Example (untested and un-tweaked but I figure something along these lines should work):

“kernel” OR “i/o” OR “disk0” OR “disk1” OR “kext” OR “loginwindow” OR “sleep reason” OR “wake reason” OR “dsmos” OR “failed” OR “reportcrash” OR “fsck” OR “sata” OR “watchdog” NOT “deprecated” NOT “sandbox” NOT “asl module” NOT “asl database” NOT “performance” NOT “ignoring” NOT “ondemand” NOT “mdnsresponder” NOT “legacy”

Etc etc. This is based on a log from Yosemite, most likely Sierra will need tweaking. The purpose is exactly what you say – getting a system log like what we used to have in console before Sierra (and if it can be even cleaner then why not). I can’t see how this is possible without multiple predicates, because Sierra spams the log like no other OS before it ever did.

Hmm. I think such compound predicates would break the command completely. The advantage of the new logging system is that it does record almost everything, but that is also its biggest problem (once you have managed to gain access to the logs).
In theory, this should be catered for in the levels supported in the log – that was Apple’s intention, that you could easily filter by looking for more ‘serious’ entries. In practice most seem to be at the same level, which defeats the design and just swamps the log.
Let’s get 1.0 reliable and productive first; I’ll then look to see if there is anything we can do to cut the noise out, and try to implement it in 1.1.
Howard.

What makes you think that compound predicates will break the command? Computers are plenty fast these days to filter text. Actually I guess a similar result can be achieved piping the output into grep with multiple arguments and it should have no trouble processing. Do you think the built-in filter works much slower than grep?