Hrrm, that sudo behavior is also broken. Looks like sudo -n is just messed up on OSX. I get this on a Linux system:

Yep works fine now..

Huh, looks like the command output has changed. I probably had something funky from all the sudo su stuff... updated output with echo $?

Oh, the "slightly different" part matters. We try to do this write immediately after forking, which is why the failure is occurring.

Ok, i can reproduce it with a user who's shell is set to /sbin/nologin ...

What's the exit status of that command? That is, if you run echo $? afterward, what does it print?

@fabe - ran that command for you...

Looking at the code, despite the daemons not starting correctly, a command exception must not be what is being thrown.

When you start the daemons as btrahan it'll try to do a sudo -u _phd .... which you might not have the permissions for.
Normally this should result in an exception and the code will start the daemon as your normal user as a fallback.
If your sudo fails without the "CommandException" phd will think the daemons have started normally.
Can you try to manually run:
sudo -En -u _phd -- scripts/daemon/phd-daemon 'PhabricatorTaskmasterDaemon' --trace --verbose --phd='/var/tmp/phd/pid'
from your phabricator dir?

I was just doing that to make them switch, since I was logged in as epriestley instead of root, so without it they would not have needed to switch. Equivalently, I can do this (as root):

(Sorry, went and had lunch)

Try with --as-current-user, just as a sanity check?

This stuff is working OK for me locally on OSX. Let me check the same codepath you're going down, my config is slightly different...

Does phd debug taskmaster work?

I don't think its starting them correctly

Hrrm, we run ps -a ... so it should still be able to find them.

The problem might be with the detection code -- maybe it's not seeing them because they're running as a different user? Are they not present in ps auxwww?

Daemons don't really seem to work for me anymore?