Still more problems than solutions

Tuesday, April 4, 2017

Having fixed the Shuttle problem (the machine has been up all night without trouble), I hoped today would be the day to finally be really productive. Alas...

Domain dinechin.org down

My personal domain is christophe at the above domain. Many of my open-source projects have that as the key, so that address is pretty important to me.

Many other family members have a @dinechin.org e-mail too. The domain was registered with Active Domain. On Saturday, my wife, who also has an @dinechin.org email address, stopped receiving any email. The configuration interface stopped working.

Several unanswered support e-mails later, I discovered I could log directly to http://active-domain.com, with a password recovery. I logged into the system. The interface had changed, being all fancy and complicated and hard to navigate. In other words, "modern", "fancy", and certainly buzzword-compliant, if a pain to use.

Of course, my list of e-mail redirects was gone. Lost in the transition to the new management system, apparently. So I began re-entering the redirects one by one. And at redirect number 10, I got a message that this was the maximum number!

Who offers only 10 redirects? To long-standing customers (my guess is probably over 10 years) who always had 3 or 4 times as many? Without any kind of warning whatsoever.

I changed service providers on the spot. Despite having another year of domain registration to go and already billed. Goodbye Active Domain.

Electric car

The car shop send me a text to inform me that my electric car was repaired. Have to get it. The nice thing is that the bus to Nice has Wi-Fi, which is pretty cool

I chose to get there around lunch time. But of course, the repair section of the garage is closed during the lunch break. Not the sales section, mind you, I could buy a new car. And while there is nobody, nothing prevents me from entering and going away with my car. I have the keys after all. But better wait and have a nice sandwich lunch on the "Promenade des Anglais" beach.

LLVM compatibility

A discussion about APIs for GPGPU forced me to talk about llvm-crap.h, where "CRAP" obviously stands for "Compatibility Restoration Adaptive Protocol".

When I setup my Jenkins for ELFE, I had the surprise to see some failures that looked like this:

[INFO]               Building with LLVM version 352

[BEGIN] opt cygwin in [top]/src [COMPILE 1/35] main.cpp In file included from compiler.h:45:0, from args.h:42, from basics.h:48, from main.cpp:52: llvm-crap.h:73:38: fatal error: llvm/Target/TargetSelect.h: No such file or directory compilation terminated.

This is on a Windows guest with Cygwin. The reason I was surprised is that this is reportedly building with LLVM 3.52. I thought this was a supported version. But apparently not. So there were more changes between 3.5 and 3.6 that I missed.

Went ahead and fixed most of that. Also pushed the externalization of the recorder.

Mail.app leaked files

Got another Mac freeze. Once again, given the symptoms, I suspect the problem with Mail.app leaking file handles like crazy. In order to both prove my theory and "fix" it, I wrote the following script:

#!/bin/bash

while true; do MAIL_PID=$(pgrep Mail) if [ -n "$MAIL_PID" ]; then FILES=$(lsof -p $(pgrep Mail) | grep REG | wc -l) echo $(date +'%H:%M:%S'): $FILES if [ $FILES -gt 400 ]; then osascript -e 'tell application "Mail" to quit' fi fi sleep 30 done

What this does is monitor the number of open files by Mail, and if it reaches 400, then politely ask Mail to quit. At 400 file handles, the system still has plenty free, so politely asking to quit is the right thing to do.

Proof that there is a leak (I keep only hte monotonically increasing values in this list) and indication of how fast this happens:

ddd@ptitpuce ~> mail-file-handles 

16:27:08: 143 16:27:38: 148 16:28:09: 149 16:29:10: 173 16:29:40: 174 16:31:42: 191 16:32:13: 209 16:32:43: 210 18:32:16: 217

So it's slowly creeping up, though there seems to be "bursts" at time. Let's see if my script protects me.

Another likely culprit is the Kaspersky antivirus program. This thing sometimes goes ahead and eats CPU like crazy. And for what, seriously? Anti-virus software is largely a scam, even more so on the Mac.