watchman: launchctl unload post-install

[wez]

This is taking a run at: facebook/watchman#358

Watchman installs and updates its own launchd.plist file on behalf of the user; it is not integrated with brew services.
In the linked issue, watchman would stop working for some homebrew users. The problem was that the launchd.plist used socket activation to set up the service, and because launchd is maintaining the socket, and the socket connection attempt just hangs, watchman never had a chance to fix up the plist and things stayed broken.

To help solve this, we're forcing an unload in the post-install portion of the recipe.

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

[MikeMcQuaid]

So, to confirm I've understood, watchman did it's own launchctl setup and this was broken so you're now removing it on post-install? How will this be fixed for existing installs inside or outside of Homebrew? Is it worth perhaps integrating watchman with Homebrew Services at the same time?

[wez]

Watchman does its own launctl setup, but because of a bug in launchd with socket activation (if you remove the binary referenced by the plist, launch will just leave the socket unconnected with no error response), combined with a bug in launchtl with not returning an error code on failure (the man page hilariously describes this as a backwards compatibility concern), combined with the strongly versioned paths in homebrew, homebrew users are sometimes left with a hung watchman instance after upgrading from an older watchman version.

Watchman 4.8 (which we're going to tag next week) removes the socket activation component for new installs, but will also have to deal with this upgrade concern before that takes effect. In the meantime (until all homebrew users are on 4.8+) we need homebrew to give us a signal when the installed version changes; the easiest way to do this is a post install script to unregister the plist deployed by watchman.

It is technically possible to configure watchman to not do its own launchd stuff, but it means deploying a global configuration file and a helper script that will cause the service to start at the appropriate time. That's something that I'd like to see happen, but not something I have bandwidth to tackle at the moment, and we'd probably still want to do something like the post install step to swing users over to the brew services approach.

Does that make sense?

[wez]

Friendly ping on this. I've got the 4.8 version update queued up behind this one :)

[MikeMcQuaid]

@wez Pulling this temporarily but just FYI that it feels a little weird to fix non-Homebrew-specific issues like this. Thanks anyway.