iOS 8.0 and excessive ‘Documents & Sync’ over LTE

“Verizon Msg: You’ve used about 50% of your 3GB data plan…”

I received this warning only 2 days before my data plan started over. I thought nothing about it at the time. Then, a few days later, after the start of the billing cycle, I got:

“Verizon Msg: You’ve used about 50% of your 3GB data plan…”

That didn’t seem right. A Gig and a half in about 20 days?! I hadn’t used any streaming service lately – especially over LTE. But, I was able to add another Gig to my plan for free, so I thought nothing of it. But, a week later, after the start of another billing cycle:

“Verizon Msg: You’ve used about 75% of your 4GB data plan”

No! This will not stand! I delved into the Cellular settings in the Settings app and found that ‘Documents and Sync’ was using way too much data – over LTE even when I was using Wifi! I called Apple and started a ticket. But, that takes time for them to come up with a solution. So, I started to document and troubleshoot. I disabled iCloud settings and found that nothing short of disabling iCloud on the device would still cause ‘data bleeding’ as I called it.

I could see it use a Meg a minute!
I could see it use a Meg a minute!

I surmised that something was wrong with some basic sync between my other iCloud-enabled devices – even over LTE – with them on the same Wifi network! At some point, I came to the and saw the iCloud Keychain.

Screenshot 2015-04-10 12.39.58

I emptied it out. I wasn’t able to backup anything in it. After about 30 minutes to make sure it wasn’t a convenient pause, the ‘data bleeding’ was stopped!

Here’s the interesting/scary thing: I had disabled Keychain sync on the iPhone and it still tried to sync!

I hope that was a bug and not how it really works!

Now, after 4 days after my data plan has restarted, I am seeing better cellular usage – and battery usage!

This is after 4 days!
This is after 4 days!


Also fixed after this, I usually had old Wifi networks in my Preferred Networks list in the System Preferences app. They were now gone!


A Quick Note on GitLab 7.4 and Remote Storage Backups

So, 7.4 came out today and among other things, includes sending backups to remote storage like  Amazon S3 storage.

Here’s a quick tip or two about getting it setup.

Example from my gitlab.yml:

 ## Backup settings
  path: "tmp/backups" # Relative paths are relative to Rails.root (default: tmp/backups/)
  keep_time: 604800 # default: 0 (forever) (in seconds)
  # Fog storage connection settings, see .
      provider: AWS
      region: us-east-1
      aws_access_key_id: _Access-ID-ID_
      aws_secret_access_key: '_Access_KEY_'
    # The remote 'directory' to store your backups. For S3, this would be the bucket name.
    remote_directory: 'unique_backup_bucket'

I kept hitting 2 walls when getting things working.

First, the region. In the docs they use a EU region. I couldn’t recall the region for the default USA region. Here are the S3 regions.

Second, was whitespace. .yml files are picky.

Settingslogic::MissingSetting: Missing setting 'remote_directory' in 'upload' section in 'backup' section in /home/git/gitlab/config/gitlab.yml
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/settingslogic-2.0.9/lib/settingslogic.rb:189:in `missing_key'
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/settingslogic-2.0.9/lib/settingslogic.rb:117:in `method_missing'
/home/git/gitlab/lib/backup/manager.rb:33:in `upload'
/home/git/gitlab/lib/backup/manager.rb:29:in `pack'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:15:in `block (3 levels) in '
Tasks: TOP => gitlab:backup:create
(See full trace by running task with --trace)

This means you have extra whitespace before the remote_directory stanza. It should align with the connection stanza.

A Quick Fix for a minor GitLab GUI Error

So I recently encountered a weird error in the Admin Dashboard of GitLab:

No GitLab-Shell Version

It wasn’t a gitlab-shell error, the bin/check script ran fine. Git and Ruby at accepted versions from the rake gitlab:check command but it did show an error:

GitLab Shell version &gt;= 1.7.9 ? ... <span style="color: #ff0000;">FAIL. Please update gitlab-shell to 1.7.9 from Unknown</span>

The fix is simple, a wrong path in gitlab.yml:

187   ## GitLab Shell settings
188     gitlab_shell:
189     path: /wrong/git/gitlab-shell/

(Some of the machine I administer use a different /home path.)

So, simply fix the path, restart gitlab and things will work.

Screenshot 2014-01-30 12.34.33