launchd .plist multiple daemon instances

[peet1]

I’m trying to make what seems like a simple launchd LaunchDaemon.

All I’m looking for launcd to do is launch the synergyc daemon ONCE. With the below plist it’s getting launched over and over … It usually tops out around 10 instances. I’ve tried both OnDemand true/false and RunAtLoad true/false.

I’m super-new to launchd plists thanks in advance

(For the life of me I cannot get this plist text to render as code … click [url=http://homepage.mac.com/peet1/net.sourceforge.synergy2.plist.txt]here[/url] for a text file )

[code]


Label
net.sourceforge.synergy2
OnDemand

ProgramArguments

/Applications/synergy/synergyc
somehostname

RunAtLoad

ServiceDescription
SynergyClient
[/code]

peet

[peet1]

The answer was too easy.

The [url=http://homepage.mac.com/peet1/net.sourceforge.synergy2.plist.FIXED.txt] PLIST [/url].

Then answer was in the NumberOfProcesses. Just needed an integer of 1.

hope this helps someone else.

peet

[peet1]

I was so wrong. That didn’t fix it. Anyone able to explain why launchd keeps spawning instances of this daemon even though I’ve got it set to RunAtLoad?

thanks.peet

[Anonymous]

I am seeing the exact same thing and cannot find a fix anywhere online. Tried the NumberOfProcesses (doesn’t work).
The logs read:

[code]Jun 23 23:16:28 Mini launchd: logcheck-hourly: respawning too quickly! throttling
Jun 23 23:16:28 Mini launchd: logcheck-hourly: 8 more failures without living at least 60 seconds will cause job removal
Jun 23 23:16:28 Mini launchd: logcheck-hourly: will restart in 10 seconds[/code]

I’ve modeled my plist almost identically to the typical daily cron jobs (except I want this particular job to run hourly on the top of every hour… “logcheck.sh”) I’ve tried setting “Nice” to 0 as well (possibly hint hear elsewhere). Nothing is working.

Argh!

[Anonymous]

Okie dokie, fought with this for hours but tweaked until I got it. For me at least it seems there were multiple things lined up to hose me. First off, that [b]OnDemand[/b] tag doesnt seem to do what the man pages say. They imply that it waits for a port or something. Even more confusing, the periodic daily launchd’s have OnDemand set to false.

The other confusing issue is the [b]Program[/b] tag. If you use this tag to point to a simple shell script, you don’ t need the other tag (ProgramArguments).

Finally, the ULTIMATE trip up was both the GROUP and the OWNER of the .plist were set incorrectly. I chown’d and chgrp’d them to root/wheel and all was fine. ("sudo chown root filename" "sudo chgrp wheel filename").

With these fixes, the simple "sudo launchctl load -w /pathto/file.plist" command works fine. Don’t need to use "launchctl start" at all.

Here’s my .plist that works (in this case for logcheck.sh) WITHOUT respawning itself into oblivion.

———————————————————-
[b]NOTE: YOU HAVE TO VIEW THE RAW HTML SOURCE OF THIS PAGE TO PULL OUT THE XML[/b]
[code]
<dict>
<key>Debug</key>
<true/>
<key>Label</key>
<string>logcheck</string>
<key>LowPriorityIO</key>
<true/>
<key>OnDemand</key>
<true/>
<key>Program</key>
<string>/opt/local/bin/logcheck.sh</string>
<key>ServiceDescription</key>
<string>Periodic run of logcheck.sh part of logsentry</string>
<key>StartInterval</key>
<integer>7200</integer>
</dict>
[/code]
————————————

Hope this helps people out there with the same launchd / launchctl spawn errors.

-Red

[Anonymous]

Thanks. Yeah, I did read the article (and others) about [i]launchd[/i]. They were all helpful in explaining the setup as well as the use of [i]launchctl[/i]. As always, running the simple example first was a good way to prove out the basics.

Unfortunately, I was seeing this runaway respawning even on the most basic of tasks (like a simple echo “hello world” type script). Switching the [i]OnDemand[/i] tag fixed this problem—weird, I agree. The system is the latest update of 10.4.6 on an Intel CoreSolo MacMini. I know I shouldn’t *have* to use the [i]OnDemand[/i] tag….which is why it took so long for me to try it….can’t explain, but it’s one more thing to try when all else fails.

As for the permissions. Well, I moved the actual file to [i]/Library/LaunchDaemons[/i] as instructed on a few tutorials ([i]/System/Library/LaunchDaemons[/i] is discouraged for this purpose). I need the “root/wheel” permissions on the .plist because the target script needs to run at root level to work (it views the some logs that are locked down for security). Per the [i]launchd/launchctl[/i] manpages the [i]launchd[/i] process is run as the user who submitted the process. This made sense, for the process wasn’t working right *until* I changed the .plist permissions.

Which brings up another interesting point. Debugging [i]launchd[/i] processes SUCKS! 👿 Yup, even with “debug mode”, I had a terrible time figuring out what that [i]launchd[/i] black box was doing. It seems to silence all output, and the man pages were terrible at pointing out who to get some output to the terminal. At least when you run [i]cron/periodic[/i] from a terminal, you get to see some output (very handy when debugging automated shell scripts). In this case, I *knew* the script was working, for I had run it from the command line several times. What I couldn’t figure out was why launchd was failing to execute it properly and why it kept respawning so many bloody instances (still a mystery). [i]Launchctl/launchd[/i] were happy to exit silently…..only a close look at the logs pointed out the respawning, but still wouldn’t explain the failure to execute. A lucky/half-educated guess pointed me to the permissions on that .plist file.

As for [i]launchctl[/i], for you newbies out there, I’ll explicitly point a few trivialities of [i]launchctl[/i] and [i]cron[/i] type jobs.
1) You can load a job with the following command
[i]sudo launchctl load -w /pathto/My_Job.plist[/i]
2) If the job is running on a [i]StartInterval[/i] it runs immediately and then every [i]StartInterval[/i] thereafter. Not bad for debugging. [i]However[/i] if the job is running on a [i]StartCalendarInterval[/i] and you don’t want to wait for the next calendar interval, you can force it with the start command.
2.1) First, get the name the job was loaded as (using [i]sudo launchtl list[/i], I think this name is the same as the [i]Label[/i] element, but I’m not 100% sure on this)
2.2) Second:
[i]sudo launchctl start My_Job <

[Anonymous]

I have a similar issue. The follow script seems to run multiple times every night. Last night it ran 1:14 AM, 1:15 AM, and twice around 2:05 AM based on the e-mails it sent.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>Label</key>
<string>net.buchanan.backupmysql</string>
<key>ProgramArguments</key>
<array>
<string>/Users/scott/Documents/mysql_data_backup.csh</string>
</array>
<key>ServiceDescription</key>
<string>Create local archive of mysql data for backup</string>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>1</integer>
<key>Minute</key>
<integer>15</integer>
</dict>
</dict>
</plist>

The script it runs is only a couple of lines.

#!/bin/tcsh
sudo tar -cvf /Users/scott/Documents/mysqldata.tar /usr/local/mysql/data/*
mail -s "mysql data backed up" [email protected] < /dev/null

I can’t figure out, based on all the documentation I’ve read why this should happen. I have another plist for another script that runs twice every night.

Any ideas?

Thanks,

[Anonymous]

The reason you are seeing multiple instances is that synergy forks then exits immediately after starting up. This behavior is not supported by launchd (says so right at the top of the man page). The workaround is to run synergy in the foreground (-f flag) and pipe its output to /dev/null. I run the server on my mac so this script is for synergys not synergc but it should be trivial to change.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
<plist version="1.0">
<dict>
<key>Label</key>
<string>net.sourceforge.synergs</string>
<key>OnDemand</key>
<false/>
<key>ProgramArguments</key>
<array>
<string>/Users/konis/Synergy/macosx/synergys</string>
<string>-f</string>
<string>–config</string>
<string>/Users/konis/Synergy/synergy.conf</string>
</array>
<key>StandardErrorPath</key>
<string>/dev/null</string>
<key>StandardOutPath</key>
<string>/dev/null</string>
</dict>
</plist>

[Author]

Posts