I have seen this issue too, on three different Lion servers (10.7.1) on which mail services are enabled. I'm not yet sure what the problem (if any) is, and how to fix it.
I am going to paste a sample log message below, since "throttling" is misspelled in your original post, and may keep this thread from being found by those searching for this issue:
com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 1 seconds
@Rusty: Thanks for that
When i'm looking in the LaunchDaemon org.dovecot.fts.update.plist: launchd is starting the following process:
/usr/libexec/dovecot/update-fts-index.pl --syslog --queued
When starting that command as root on the server i didn't get an error in the syslog.
As an other option there is set the "QueueDirectories" as "/var/db/dovecot.fts.update".
Looked in this directory i have a file ".<username>.INBOX" with 0kb.
So I unloaded the org.dovecot.fts.update with "launchctl"
Backuped that file and removed it.
Reloaded the org.dovecot.fts.update with "launchctl"
No the process is running fine - no errors are given in the syslog. The file isn't created anymore, but mail-server is still running fine and mails are still all visible.
For testing I moved back the backup, and immidiatelly the process is crashing again.
Didn't know exactly what that process and db-file should do?
As long as this is a test server, i would say: removed that file and the process is running back fine
After a reboot the file is back there and the logs a spammed by the error.
Deleting that file will immediatelly stop the error. After a few hours the file is back in the dir (0kb) and the error is back.
Had a look in the logs, and the error reapears as soon as fetchmail is fetching a mail. Deleting the file would stop the error until a new mail arrives.
@Rusty do you have mail-service active? Are you fetching your mails with fetchmail?
Same error here... Lion Server 10.7.1 running Mail service with active OD accounts. Mail is being fetched with Mail.app from a variety of client OS including Lion, Snow Leopard, and Leopard. Error messages began cropping up after running the server for a few days. Here's a log excerpt from System.log.
Sep 15 08:17:14 smtp com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 9 seconds
Sep 15 08:17:25 smtp com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 8 seconds
Sep 15 08:17:35 smtp com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 9 seconds
Sep 15 08:18:13 smtp com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 2 seconds
Sep 15 08:18:22 smtp com.apple.launchd (org.dovecot.fts.update): Throttling respawn: Will start in 4 seconds
Stress Test wrote:
Rusty Ross wrote:
Mail service is active.
Mail is being fetched by a variety of IMAP clients.
Your server is a mail-server with a public IP-address where the mails are sent to? Or how do you get the mails to the server?
That's right. A fully-public MTA.
Also note that I have observed this issue on multiuple Lion Server boxes, all of which basically fit the same criteria as the specific machine I am describing here.
So based on my reading - here is what I think is happening. (The short story - this is behaving as expected.)
When email is received by dovecot, it modifies a file in the queue directory, triggering launchd to update the full text search index.
Launchd, wisely, doesn't want to re-run the update script too often for efficiency purposes, so if a new file is placed in the queue directory within 8-10 seconds after the prior script finishes (e.g. from a new email), will delay running the update script.
So, in my opinion, the main problem is the spamming of the logs with the launchd messages.
> 05-19-2008, 05:55 PM
> the "Throttling respawn" message is an intentional behavior of launchd; it tries to conserve system resources by preventing a job from running more frequently than every 8 or 10 seconds (if you need something that needs to check in with the system more frequently than that, you can either override the respawn limit or construct your script as a stay-open script, rather than as a triggered or timed script). as to why you're getting this message... at a guess, either your script is taking longer than 300 seconds to execute (which will keep launchd continually trying to launch it, and continually choking because the job is already running), or you've got some other trigger than the 300 second one which is getting in the way.