Resuming paused processes on macOS

My Macbook Pro has been annoying the hell out of me lately, running of out application memory on a regular basis. (You’d think that’d be hard to do with 16 GB of RAM, but apparently my Mac is quite good at it…) Sure, I can restart it to clear the memory and have it load things up again as needed, but there always comes a point when that little window pops up and complains about a lack of application memory.

A couple of times I’ve dismissed that window by mistake and wondered how to restart the suspended application(s). A quick search yielded an option to the kill command that I wasn’t aware of. So the next time I do that by mistake and leave an app or two suspended, I can start up the Activity Monitor, check the process ID of the suspended application(s), and then type:

% kill -CONT <PID>

Hey Presto, app gets unstuck. Yay!

That is, as long as macOS doesn’t decide to suspend the terminal…

On backups

In my previous post I mentioned that I’d been using CrashPlan for making backups on our Windows PC. Like many, I prefer to get a feel for the software before I pay for a copy, so I installed the free version. It all seemed to set up OK, I didn’t immediately come across any missing features and so I left it alone to do its thing.

And in the absence of any error messages I believed that it was working just fine. Alas, that was not the case.

In checking out my backup drive when dealing with our Trojan infection, I found out that CrashPlan had filled its allotted hard drive and in fact hadn’t backed up anything in weeks. And in the process had utterly failed to alert me to that fact. Hey CrashPlan – how about using the Windows notification area for alerts? I mean, a backup failing is a major error and the user should be told about it as soon as possible.

One of the reasons I installed CrashPlan in the first place was that I wanted something that was more intelligent backup than Windows’ own. However, the free version of CrashPlan has a set of default settings for the backup frequency and number/age of versions that runs the risk of filling your backup hard drive then nothing more will be backed up because nothing will be old enough to delete. CrashPlan’s official advice on solving this problem? Get a bigger hard drive. Okaaay….

OK I could solve this problem by paying for the basic version, which includes unlimited online backups too. After all, $60 a year isn’t that much to pay for peace of mind is it? Normally I’d argue that is cheap, but in this case all I wanted was a local fire-and-forget backup of our primary documents directories that didn’t rely on me remembering to run rsync. And $60 was too much for just that.

Enter Windows FileHistory. I hadn’t heard of it until I searched again for Windows backup solutions. After a bit of fiddling about (tip: don’t include any folders that have a frequently-updated cache, like that for a web browser!) I seem to have it working just fine. It’s been going for a few days now, and is updating only what it needs to update which is pretty much all I want in a backup program!

However, I’m not entirely convinced that it’s a long-term solution as it seems a bit fragile. When configuring FileHistory, it seemed to get itself into a state where I couldn’t add new folders to the backup, and remove one would remove them all. A round of disabling it, reboot, and re-enabling FileHistory fixed it, but I shouldn’t have to do that every time. (I shouldn’t have to do it at all, of course…)

So we’ll see how it goes. I didn’t like the fact that CrashPlan forced me to create yet another account even to use the free version – my Windows 10 box uses local logins, so no additional accounts needed to use FileHistory. Plus I’ll keep doing my rsync backups to the Linux box, so at least I’ll always have a second copy. Mind you, even that backup drive is filling up…

Postscript: I should admit some fallibility here. My initial backup plan included a directory tree that mistakenly contained our web browser caches, which of course tend to a) be large and b) change frequently. (Not to mention that they are pointless to back up!) That meant every time the backup ran, it saw that a few GB of files had changed and duly did exactly what I’d asked it to do. Alas, this resulted in my paltry 160 GB drive filling up way sooner than expected. So one of the things to make sure when you set up a backup is to make sure it really is only backing up the files that you wish to keep! I know this now… πŸ™‚

Feeding your algorithm

The other day I included the phrase “stupid Instagram” in the caption for a photo on Instagram. I was quite proud of the photo, and figured it was a decent contribution to Mountain Monday. I was expecting a steady stream of likes, probably topping out around 30-40 or so (which is typical for me). So imagine my surprise when nothing happened. I got a couple of likes early on, then one or two more and finally another couple from followers whom I suspect have relatively short follower lists.

And that was it. A grand total of 9 likes in nearly 48 hours, none of which were from what I would describe as my “mutual admiration circle”; people with whom I tend to exchange likes. I was baffled, but then I began thinking about the fact that Instagram’s feed is now driven algorithmically and is not just a timestream (which I would prefer), and I wondered if the fact that I’d written “stupid Instagram” meant that Instagram’s algorithm significantly down-weighted my post to the point where almost none of my followers saw it? Could Instagram really be that sensitive to even the slightest perceived criticism?

Now, of course I realize that many of the people I follow have really long lists of others they follow, so it could simply be a numbers game. And I have seen that happen in the past, but I still usually rack up 20-30 likes. (By comparison, my latest photo is up to 35 likes in less than three hours.)

So I will try another experiment in the near future. I might even post the same photo, at the same time of day with all the same tags and caption, only with the perceived slight on Instagram’s part removed. And I’ll see what happens.

A passing encounter with ransomware

It all began with the most innocuous of actions: a click. One of those many articles on Facebook that pops up in the “Related stories” area when you “like” an article. Next thing we had a web page showing all manner of error codes along with advice on how to fix the “problem” that had been detected, pop-up dialogs galore and the computer began beeping, like the alarm system on a science-fiction spaceship. It was almost comical.

Until I realized what was happening.

Then I had the “Oh shit – ransomware” moment, and lunged for the power button. (In retrospect I should have just tried to shut down the web browser from the task manager but I didn’t want to delay shutting down the computer if it was about to start encrypting our hard drives.)

That done, I thought for a moment, trying to assess the damage in the worst case that the hard drives had been encrypted. We figured that we might lose the past two weeks of photos and any edits. That wasn’t too much of an issue, really as we hadn’t cleared the memory cards in our cameras for over a month. We would probably lose a few recent PDFs and text files – annoying but not disastrous.

Having weighed up the situation, I retrieved some cables for reading bare hard drives and then set about dismantling the computer. First I detached the external hard drive used for continuous backup of a few folders (more on that later). Then I opened the case and removed the 3-TB main hard drive that contains all our photos and documents.

I booted up the Linux box and plugged in the external backup drive. It mounted just fine and I could read the files on there – at least as much as you can read the files in a CrashPlan backup. There was no sign of any recent modifications to the file system, so I figured that if something had started the encryption process, it hadn’t got to that drive yet (after all, it was down the list at F:).

I breathed a sigh of relief: it looked like we’d actually have up-to-date copies of our documents. Yay!

Next step was to attach the 3-TB drive. That’s when my heart started to sink. It mounted as an empty volume. No partitions, nothing. Wait, that’s not quite true. In actual fact it didn’t even mount – it just showed up as empty in the disk utility. Oh crap. Was that it? Had we actually lost the contents of that drive? I didn’t dare hope it was just some quirk.

Unplugging that drive, I moved on to the main system drive. Plugging that in was immediately more hopeful: a partition called “System Restore” mounted, and then I got an error message saying that the main partition couldn’t be mounted because Windows had been put in hibernate mode. Another light bulb moment, this time a positive one – I think – as I remembered I’d configured the power switch to hibernate rather than power off. OK, so the drive had gone into hibernation correctly. I mounted it read-only and lo-and-behold I was in business.

Poking around on the C: drive it appeared that everything was in order. I couldn’t find any nefarious-looking files (not that I really knew what to look for) with the right timestamp. So I decided to make a local backup, just in case. I used the tried-and-tested rsync to make a copy on one of the drives in the Linux box, which gave me time to do a bit of research about ransomware…

What I found gave me hope. It seemed that a couple of the most common types were in fact browser-based and weren’t real ransomware at all. I looked at screenshots to compare with the picture in my memory from the brief glimpse I took before hitting the power button, and decided that – if I was lucky – we’d most likely been hit with the TechBrolo.C Trojan installer. Furthermore, Windows Defender seemed to know about them and could remove them.

Progress of sorts, then. Once my local backup was done, I decided it was time to test those ideas, and got back down on my hands and knees to reattach the hard drives. Leaving the network cable unplugged, I tentatively hit the power switch. I was soon looking at a normal login screen – very promising, which told me we hadn’t been hit by real hard-drive-encrypting ransomware. I logged in and waited. Everything looked fine. I checked the 3 TB drive and was relieved to see that all our files were still there. I started up ACDSee to browse some photos just to be sure. All looked OK. Phew!

I restarted Firefox – which of course tried to load all the previously-open tabs. At least this time I was able to kill the tab with the offending payload, and looked through the history to see what website had spawned it. I copied the URL and deleted the entry from the history. I won’t give the URL as I would hate for someone else to click on it, but the site is in the .ml top-level domain (which is Mali, where Timbuktu is located).

Everything still looked fine, so I started up Windows Defender and set it to run a full scan. However, not long after it got under way, a warning sign did show up saying that a potential malicious file had been discovered.

When the scan ended (two-and-a-half hours later), the report did indeed show a single potential threat: the TechBrolo.E trojan, hiding in our Firefox cache. I clicked “Remove” and within moments it was gone. I re-ran a quick scan just to double check and it came back clean. Yay! I plugged in the network cable, started the task manager and waited. Nothing was happening: just an idle computer. Next up was Firefox again, and it too wasn’t doing anything out of the ordinary.

Now, remember that backup I did on my Linux box? Well, that included the Firefox cache, so I went in and had a look. Sure enough the file was a gzipped Javascript file with some stern warnings and more newlines than I’ve ever seen in my life! It looks like it tries to load a PHP file with an insane name, which I’m guessing is where the main payload is.

I wonder if the Javascript downloaded is country-dependent? I mean, showing a ransomware web page with a 1-8XX number won’t get you very far outside the US and Canada.

And so there I was a few hours later, and all was as well as it could be.

At the end of the day, all I can say is I’m glad I had that Linux computer, both as a second (and more importantly non-Windows) computer and as a backup for all the files we care about, as well as having the right cables to connect hard drives to a USB port. I’m also glad that I could shrug and say that at worst, we’d have lost only a couple of weeks’ documents and photos.

My take away from this? Have a backup of all the files you care about. And make sure that backup runs as often as you need it to. Every day, if necessary, though weekly is probably good enough. And watch what you click on…!

Terminal trees

A long time ago, back when I got my first Mac, I installed MacPorts to get a few extra packages that I used under Linux. Fast forward a few years (and a new laptop) and I’ve forgotten about all of this πŸ™‚ When it came to looking for a way to get the tree command (which displays a directory listing in a tree format), one of the answers was to use MacPorts which prompted me to check and lo-and-behold, I did indeed have MacPorts installed.

A quick check showed that my installed version was waaaaay out of date so I needed to update that before going ahead with installing the package I was after. Thankfully, MacPorts has a nice little migration guide that helped me through the process. (This kind of documentation is vital to cover those instances of redoing something that you might only touch one or twice in the lifetime of a computer.)

Of course, I had to reinstall the Xcode command-line tools along the way… (Why they aren’t included by default I do not know.) I also trimmed my list of port installations to drop a couple I knew I wouldn’t need (such as Perl, which I manage separately with Perlbrew).

Then all I had to do was:
% sudo port install tree
refresh my path and I was good to go. Yay! (Ignore the spacing in the example below – it seems the preformatted text for this WP theme adds some extra padding which breaks up the connecting lines. It should look fine in the terminal.)

β”œβ”€β”€ Desktop
β”œβ”€β”€ Documents
β”œβ”€β”€ Downloads
β”œβ”€β”€ Library
β”‚Β Β  β”œβ”€β”€ Keychains
β”‚Β Β  β”‚Β Β  └── ....
β”‚Β Β  └── Preferences
β”œβ”€β”€ Movies
β”œβ”€β”€ Music
β”œβ”€β”€ Pictures
└── Sites

It seems that folks tend to prefer HomeBrew over MacPorts but that’s something for another day.

TensorFlow installation

I found this helpful little intro to using Google’s TensorFlow machine learning library with Python. Next step: install TensorFlow on my laptop.

A quick check of the project docs shows how it easy it is to install – I used pip. For simplicity (and the fact that I’m not planning to do any heavy ML stuff just yet) I went with the CPU-only option for Mac OSX (aka macOS since I’m on Sierra), and since I use tcsh rather than bash I used setenv to point to the TF_BINARY_URL.

But then I hit the following error:

Cannot remove entries from nonexistent file /opt/anaconda/anaconda/lib/python2.7/site-packages/easy-install.pth

A search told me that this was an issue with setuptools, but – thankfully – there is a workaround: append --ignore-installed to the installation line and hey presto, all is well.

(Funnily enough, most of the top results when searching for this error are related to installing TensorFlow. Coincidence, Google?)

After that, the tutorial examples worked just fine. Step 1 on the TF/ML learning curve…