Docker Desktop for Mac Won’t Start?

Docker logo

I have been using Docker Desktop for well over five years with very few problems besides the typical host-to-container mount performance issues. After a recent upgrade to Docker Desktop, I was surprised to notice that Docker Desktop would no longer start. It just reported a “Docker Desktop starting…” message and wouldn’t continue.

I tried the typically suggested approaches:

  1. Checked to ensure I was running the latest build of Docker Desktop
  2. Via the Docker > Troubleshoot menu
    • Clean / Purge data
    • Reset to factory defaults
    • Uninstall
  3. Reinstall Docker
    • Remove Docker from /Applications and empty Trash
    • Restart the computer
    • Reinstall Docker Desktop for Mac

Finally, after about two hours, a post on forums.docker.com by zcqian put me on the right track, so I wanted to promote it, along with some refinements and my complete solution (try parts or the complete procedure).

  1. Restart the computer, and make sure Docker is not running. If it is trying to start, then stop it and close it.
  2. Open your Applications folder and delete Docker, then empty the Trash (or brew uninstall docker).
  3. Open Terminal and type:
    rm -rf ~/Library/Group\ Containers/group.com.docker
    rm -rf ~/Library/Containers/com.docker.*
    rm -rf ~/Library/Application\ Support/Docker\ Desktop
  4. Download Docker Desktop again, and copy Docker to your /Applications folder (or brew install --cask docker).
  5. Open Docker.

With any luck, you will now be back up and running again. Feel free to leave a comment if these steps change over time, and I will update this post accordingly.

Displaying Dates Using User Selected Timezones in Laravel 4

Let me start by saying, you can safely stop worrying about user selected timezones if you are using Laravel 4+. I just spent a few hours trying to determine what was generally the most accepted method to store and display dates using a users own timezone. As it turns out, it is way too easy. So much so that I was finding it difficult to locate up to date Laravel 4 discussions on the topic.

So in case you are as thick as I am, here it is, all spelled out for you.

Important First Step: Set the timezone in app/config/app.php to your preferred timezone (or leave it at UTC if you want) keeping in mind that you will never change this, and you will never do something terrible like Config::set(‘app.timezone’, Auth::user()->timezone); anywhere in your application.

Using the following users table as an example, assume that we want to show foobazed_at to the user using their selected timezone:

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(255) NOT NULL,
  `locale` varchar(255) NOT NULL DEFAULT 'en',
  `timezone` varchar(255) NOT NULL DEFAULT 'America/Toronto',
  `foobazed_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `deleted_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
) ENGINE=InnoDB;

Laravel by default converts created_at, updated_at, and deleted_at columns to instances of Carbon, which, not knowing what Carbon was at the time didn’t mean a whole lot to me. Well, let me tell you… Carbon is awesome.

Instead of doing the following to display the created_at date (which will show the date in the default application timezone):

echo User::find(1)->created_at;

You can simply do this to get created_at in the users own preferred timezone:

echo User::find(1)->created_at->timezone(Auth::user()->timezone);

This is all well and good for the default columns, but what about our foobazed_at date? Easy. In your model (in this case the User model at app/models/User.php) add the following method:

public function getDates()
{
    return array('foobazed_at', static::CREATED_AT, static::UPDATED_AT, static::DELETED_AT);
}

That’s it! Any time you want to display foobazed_at you can simply do this:

echo User::find(1)->foobazed_at->timezone(Auth::user()->timezone);

I hope this is useful to someone else.

Cleaning Up Is Hard To Do

Linux TuxI have been administering Linux servers for a while now so coming across a new problem is both exciting and stressful, especially when that problem is on a high demand production server. I recently came across one of these scenarios, and was surprised how difficult it was to solve.

I had a single directory on a server that contained millions and millions of tiny 32Kb text files (which were actually non-sharded PHP session files that didn’t get caught in garbage collection, and went unnoticed for months on a busy server). The interim fix to that problem was easy:

mv /var/php/sessions /var/php/sessions.evil && mkdir /var/php/sessions

The real problem was that I was left with this sessions.evil directory that I couldn’t delete, ignore in snapshot backups, or even list of the contents of because there were just too many files and going anywhere near it would use too much disk I/O and cause the load on the server to spike.

After using / writing various Bash, Python, PHP, etc, scripts that caused too much load on the server I happened across this genius solution by Zhenyu Lee (and a comment by Paul Reiber)… to use rsync instead of rm, find, xargs, etc:

On a CentOS box and using my example directory of /var/php/sessions.evil, which was owned by root:apache do this:

cd /var/php
mkdir empty_dir
chown root:apache empty_dir
rsync -vvvv -a –delete empty_dir/ sessions.evil/

Depending on how many files are in your sessions.evil directory this could take a while (2 days in my case), but the 5 minute load average on the server stayed between a manageable 2.0 and 3.0. My twist to Zhenyu’s solution was to add some verbosity (-vvvv) in there so I could tell that rsync was actually doing something.

Paul’s next comments are important though, so once rsync is eventually done mirroring your sessions.evil directory with your empty_dir pay attention:

rmdir sessions.evil
mkdir sessions.evil
rmdir sessions.evil empty_dir

The first rmdir sessions.evil will cause a bit of a load average spike for a few minutes, but once it’s gone… whew.

Well there you go, happy rsyncing, and a huge thanks to Zhenyu Lee for posting that unique and brilliant solution.