Sun 12 Nov 2006
Workaround Bonjour No More on Intel Macs?
Category : Technology/WorkaroundBonjourIntelMac.txt
This is interesting. I just realised that I don't get the Workaround Bonjour stall on my Intel iMac anymore.
I wonder when that started to happen. I remember checking if it's still there when I updated my machines to 10.4.8, and was disappointed that it still was.
Perhaps, I've only tested it on my G4 iBook? So, to be sure, I went back to the G4 iBook and, sure enough, it's still there. It still stalls everytime a call is made to launchd load.
So, maybe I hadn't tested it on my Intel iMac. Anyway, it's gone, on that machine. I've only got that one Intel Mac. I would love to hear it if anyone else can confirm it.
Thu 20 Jul 2006
Working around Workaround Bonjour
Category : Technology/WorkingAroundWorkaround.txt
I've updated both DNS Enabler (to 2.0.9) and MailServe (to 2.1.6) to handle the bug introduced by the OS X 10.4.7 update (that "Workaround Bonjour" thing) whereby the system would stall for about 60 seconds whenever a call is made to /bin/launchctl to start a launchdaemon (like BIND, Fetchmail, etc).
I've changed DNS Enabler so that the Restart DNS button avoids calling launchctl, so that the only time you actually see the stall is when you first start the DNS service (be patient - it'll clear - and the DNS Server will still work correctly), and not when you stop the service, and especially not when you restart the service to make changes to your DNS data, which is pretty much what we do most of the time.
I've done the same to the Restart Fetchmail button in MailServe, so that you don't get held up when you need to change Fetchmail parameters.
It's important to note that this happens only on 10.4.7, and that the DNS and Fetchmail services (as well as Postfix, POP, IMAP, etc, i.e, anything started or enabled using launchctl) are all still launched correctly.
Up to now, I've ascertained that this stall only happens when an application makes a call to the "/bin/launchctl load" comamnd (well, sometimes on launchctl unload, depending on the sequence of the calls you make). I believe this is probably an unfortunate side effect of the security-related changes Apple made to patch up the launchdaemon mechanism (launchd) in the 10.4.7 update.
Tue 04 Jul 2006
Category : Technology/BonjourMystery.txt
The 10.4.7 "launchctl load / Bonjour Workaround Error" mystery deepens. I've been searching for an answer for hours. Nothing turns up from a Google search and I wonder who else is affected by it.
Launchctl is used to turn or off the network-related daemons, like Bind, Fetchmail, Postfix, POP, IMAP, and even the Bonjour (previously known as Rendezvous) service itself.
I've turned off Bonjour (not that I want to, because it's built so closely into the fabric of Mac OS X, e.g., BBedit crashed as soon as I turned off Bonjour), to see if it'll stop the workaround error from occuring. But no change, it still does.
Even reloading Bonjour will throw up the "Workaround Bonjour: Unknown Error" as shown below :
So, in 10.4.7, Workaround Bonjour occurs every time a call to /bin/launchctl is made, no matter which services are launched. And it affects both PPC and Intel Macs updated to 10.4.7.
The thing is, the launchctl command actually succeeds and completes. But it'll be followed by the Workaround Bonjour command(?) which executes and then just hangs there. Where did that come from? That's the big question.
From the point of view of a user using DNS Enabler, or trying to enable Postfix, IMAP, POP or Fetchmail (as opposed to just restarting Postfix, POP or IMAP), he'll see the progress indicator spin for a long time, until the application decides to time out and return control to the user.
Actually all the services have completed successfully - if the user has the patience to wait for a minute or so - and all the Postfix, DNS, POP, IMAP, Fetchmail services would have been set up correctly, even before the Bonjour Workaround Error hang-up occur.
But watching the progress indicator spin for a minute or so, I'm sure the user would (reasonably) feel that something has gone wrong. Wait is what the user should do, because the Bonjour Workaround would eventually time out.
Remember this only came with 10.4.7. And the services, once enabled, will work correctly as usual, even across reboots. It's just that the "enabling" process will seem to take longer (when it used to take a mere few seconds).
So, don't be in a hurry to update your server. Wait for things to be fixed.
Conversely, that's why I do the updates as soon as they appear - it's better that I know before I'm swamped with mail from the users. The search continues. I'm starting to hate this thing called Bonjour.
Mon 03 Jul 2006
Bonjour Error in 10.4.7
Category : Technology/BonjourError.txt
This snippet from my Terminal session shows when the Bonjour error occurs, when I try to restart Fetchmail :
The problem is at the "launchctl" line, which launches the Fetchmail launchdaemon (which is also used to launch the BIND launchdaemon and that's why DNS Enabler is also affected).
The launchctl command executes and returns quickly, as it is expected to, but after that we get the "Workaround Bonjour: Unknown error: 0" line, which hangs indefinitely until both MailServe and Enabler give up and return control to the user. In both cases, Fetchmail and DNS services are launched correctly, but the user thinks that the system hangs because the progress indicator spins for a very long time before control is returned to the user.
So the question is : why did this Bonjour thing appear in 10.4.7 and how do we get rid of it?
Fetchmail and 10.4.7 Problem
Category : Technology/MailServeBonjourError.txt
I'm seeing a problem that has been introduced with the OS X 10.4.7 update that affects Fetchmail. I get a "Workaround Bonjour: Unknown error: 0" when I try to restart Fetchmail.
From the MailServe interface, if you try to Restart Fechmail, you will see the progress indicator spinning for a long tme before it stops. If you look into the Console log, you'll see that Bonjour-related error, though how Bonjour got into the picture is beyond me at this point. This affects both PowerPC and Intel Macs.
I'm going to trace through this and hope I find a solution.