- launchd-dev - lists.macosforge.org

launchd check-in: Where's the documentation?
by Sidney San Martín 11 Aug '09

11 Aug '09

I can't find any documentation on the launchd checkin process. Using SampleD, launch.h, and other people's documentation of their discoveries it's possible to put together a working daemon, but with no guarantee that you're doing everything right. (Even though launchd is open source, its APIs need documentation.) launchd.plist(5) is the first place I even saw the check-in process mentioned: "The job must check-in to get a copy of the file descriptors using APIs outlined in launch(3)". launch(3) doesn't exist (<rdar://problem/7130390>). It seems like the following, at least, should be documented: 1) What check-in is and when it is necessary 2) The consequences of a job not checking in when launchd expects it 3) What keys in the response dictionary are filled in at runtime 4) How to memory manage launch data returned by check-in functions (i.e. what needs to be released) 5) Error conditions and how to handle them What do you think? Has this come up before? Is there some secret store of documentation I'm missing? Is this API so intuitive that documentation is redundant?

2 2

launchd & mDNSResponder: "Policy denied Mach service lookup"
by Björn Giesler 10 Aug '09

10 Aug '09

Hi, I've recently migrated to a new MacBook Pro, and since that migration, found that Bonjour no longer worked, and indeed that all applications that used Bonjour just hang. I've traced this to what looks like a problem in the interaction of mDNSResponder and launchd; the log messages I get are lots of com.apple.launchd[1] (com.apple.mDNSResponder[2551]): Policy denied Mach service lookup: com.apple.distributed_notifications.2 etc.etc. with different services. I don't yet quite understand how launchd and launched processes interact. Why is launchd responsible for service lookups for other applications? Where are policies stored? etc. The manpage says nothing about this. I've tried looking for the above message in the launchd code and found it in launchd_core_logic.c in the SULeopard branch, which introduces the mspolicy_* functions, but I'm afraid I can't make much sense of it. I'll try to compile my own launchd and step through it, but it would be nice if somebody could push me in the right direction. (Is there even some documentation on this?) As a Unix rc guy, launchd is a twisty maze of passages, all alike... Thanks in advance & Regards, Björn

2 6

TimeOut key — how long should a job really stay alive?
by Sidney San Martín 07 Aug '09

07 Aug '09

I'm building a daemon that uses a launchd-provided socket, it seems like a good idea to exit when nothing's connected. I've read that jobs must stay alive for 60 seconds, but launchd is giving me a 30 second timeout at checkin. What's right? How are daemon timeouts supposed to work?

2 3

Re: [launchd-dev] launchd-dev Digest, Vol 25, Issue 7
by Nehemiah Dacres 31 Jul '09

31 Jul '09

why is the perror command only in MySQL this should be in every Linux. is there a way to toss this into Snow Leopard at the last Minuit? I could have done it in one line but it wouldn't be polite (as a program or as readable code) #include <unistd.h> #include <stdio.h> #include <string.h> int main (int argc, char** argv){ if (argc != 2) printf("usage: %s errnum\n",argv[0]); else printf("%s\n",strerror(atoi(argv[1]))); return 0; } On Thu, Jul 30, 2009 at 9:00 AM, <launchd-dev-request(a)lists.macosforge.org>wrote: > Send launchd-dev mailing list submissions to > launchd-dev(a)lists.macosforge.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev > or, via email, send a message with subject or body 'help' to > launchd-dev-request(a)lists.macosforge.org > > You can reach the person managing the list at > launchd-dev-owner(a)lists.macosforge.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of launchd-dev digest..." > > > Today's Topics: > > 1. Fwd: Stray process with PGID equal to this dead job (Johannes) > 2. Re: Stray process with PGID equal to this dead job > (Damien Sorresso) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jul 2009 16:07:02 +0200 > From: Johannes <list100(a)hoerburger.org> > To: launchd-dev(a)lists.macosforge.org > Subject: [launchd-dev] Fwd: Stray process with PGID equal to this dead > job > Message-ID: <CEDB4D6B-CB34-40A0-A4A6-01F243981CFB(a)hoerburger.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > OK, solved it by myself, did it the weird-apple way: > A launchctl triggered backupfather.pl now creates Launchagents.plist > for every child process including the calling arguments and triggers > launchctl load/start for these creations... > > a lot of useless filewriting just for backgrounding processes for > which a normal "&" would be enough as it seems but at least it works... > > Greets > Johannes > > Am 27.07.2009 um 20:26 schrieb Johannes: > > > Sorry for reopening a thread that was already dealt with, but I ran > > into a serious problem that I'm not able to workaround in any way. > > > > I have a perlscript (let's call it backupfather.pl) that calls a > > second perlscript (backupchild.pl) 15 times for initiating rsync > > over ssh backups from 15 different client-hosts. > > > > The callerscript knows how to deal with open processes (keep them > > running for a designated time, kill them if the target host where it > > fetches the backup from isn't reachable or the backup script is > > overtime, don't launch the child script for a specific host if one > > process like that is still running) > > > > Additionally it knows how to deal with the child processes of > > backupchild.pl (rsync and ssh) building up pid and parent pid trees > > and killing all involved before launching again with the same > > arguments. > > > > So the processmanagement itself is clean. > > > > In order to start the backupchild.pl script 15 times I need to > > background them. They may rund serveral hours so the backupfather.pl > > has to get free to initiate the finished backups again after an > > hour, not initiating the still running ones. > > > > I've tried several ways to get out of the launchctl processgroup > > prison the backupfather.pl is running in. > > > > setpgrp doesn't work on Mac OS X (that way it would be possible to > > let it run under the root's processgroups ID). > > > > forking and exiting the backupchild.pl didn't help eighter, nore did > > creating 15 instances for each client backup and launching them as > > necessary. As soon as it comes to backgrounding I'm stuck in: > > > > "Stray process with PGID equal to this dead job: PID _pidnumber_ > > PPID _parentpidnumber_ perl" > > > > Any ideas how to get the backupchild.pl processes out of the > > launchctl prison? > > > > Thanx in advance for any help, > > Johannes > > PS: If you're wondering why I don't use TimeMachine for Backups: > > We've used it till AppleFileServer started eating 100% CPU on the > > Server, rendering the Fileservice for the regular AFP Fileservice > > Clients unusable, while SSH at the same time had fullspeed and no > > problems. So splitting backup from fileservice was the deal for > > making fileservice useable again... > > > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jul 2009 08:58:00 -0700 > From: Damien Sorresso <dsorresso(a)apple.com> > To: Johannes <list100(a)hoerburger.org> > Cc: launchd-dev(a)lists.macosforge.org > Subject: Re: [launchd-dev] Stray process with PGID equal to this dead > job > Message-ID: <0D2CAC6A-092D-4D16-A2E7-80AB2AF5FEF8(a)apple.com> > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > On Jul 27, 2009, at 11:26 AM, Johannes wrote: > > Sorry for reopening a thread that was already dealt with, but I ran > > into a serious problem that I'm not able to workaround in any way. > > > > I have a perlscript (let's call it backupfather.pl) that calls a > > second perlscript (backupchild.pl) 15 times for initiating rsync > > over ssh backups from 15 different client-hosts. > > > > The callerscript knows how to deal with open processes (keep them > > running for a designated time, kill them if the target host where it > > fetches the backup from isn't reachable or the backup script is > > overtime, don't launch the child script for a specific host if one > > process like that is still running) > > > > Additionally it knows how to deal with the child processes of > backupchild.pl > > (rsync and ssh) building up pid and parent pid trees and killing > > all involved before launching again with the same arguments. > > > > So the processmanagement itself is clean. > > Why bother creating your own tree? You already have a process tree > maintained by the kernel. "Clean" process management is having the > parent kill and reap its children as necessary and allowing the > semantics of POSIX parent-child relationships to create a chain of > responsibility. > > So if your job sends SIGTERM to its immediate child, that child will, > in turn, forward the SIGTERM to its children, wait for them to exit > and then die accordingly. > > > In order to start the backupchild.pl script 15 times I need to > > background them. They may rund serveral hours so the backupfather.pl > > has to get free to initiate the finished backups again after an > > hour, not initiating the still running ones. > > > > I've tried several ways to get out of the launchctl processgroup > > prison the backupfather.pl is running in. > > "launchctl process group prison"? I think you mean "POSIX standard > behavior". Your child processes inherit a PGID equal to that of their > parent's PID. launchd has nothing to do with this behavior; it's > enforced by the kernel. launchd complains about this because your > job's has attempted to daemonize without calling setsid(2), setpgrp > (2), etc. > > > setpgrp doesn't work on Mac OS X (that way it would be possible to > > let it run under the root's processgroups ID). > > Mac OS X conforms to POSIX, so setpgrp(2) does work. What errno does > it set when you call it? Are you calling it from the child process > with 0 as the first argument, or from the parent with the child's PID > as the first argument? > > Also, please read setsid(2). > > > forking and exiting the backupchild.pl didn't help eighter, nore did > > creating 15 instances for each client backup and launching them as > > necessary. As soon as it comes to backgrounding I'm stuck in: > > > > "Stray process with PGID equal to this dead job: PID _pidnumber_ > > PPID _parentpidnumber_ perl" > > > > Any ideas how to get the backupchild.pl processes out of the > > launchctl prison? > > > I would recommend making backupchild.pl into a launchd job that your > main job kicks off by running `launchctl start`. If you need multiple > instances of the job, you can create them on the fly with `launchctl > submit`, and launchd will take care of the process management. > -- > Damien Sorresso > BSD Engineering > Apple Inc. > >

2 1

Stray process with PGID equal to this dead job
by Johannes 28 Jul '09

28 Jul '09

Sorry for reopening a thread that was already dealt with, but I ran into a serious problem that I'm not able to workaround in any way. I have a perlscript (let's call it backupfather.pl) that calls a second perlscript (backupchild.pl) 15 times for initiating rsync over ssh backups from 15 different client-hosts. The callerscript knows how to deal with open processes (keep them running for a designated time, kill them if the target host where it fetches the backup from isn't reachable or the backup script is overtime, don't launch the child script for a specific host if one process like that is still running) Additionally it knows how to deal with the child processes of backupchild.pl (rsync and ssh) building up pid and parent pid trees and killing all involved before launching again with the same arguments. So the processmanagement itself is clean. In order to start the backupchild.pl script 15 times I need to background them. They may rund serveral hours so the backupfather.pl has to get free to initiate the finished backups again after an hour, not initiating the still running ones. I've tried several ways to get out of the launchctl processgroup prison the backupfather.pl is running in. setpgrp doesn't work on Mac OS X (that way it would be possible to let it run under the root's processgroups ID). forking and exiting the backupchild.pl didn't help eighter, nore did creating 15 instances for each client backup and launching them as necessary. As soon as it comes to backgrounding I'm stuck in: "Stray process with PGID equal to this dead job: PID _pidnumber_ PPID _parentpidnumber_ perl" Any ideas how to get the backupchild.pl processes out of the launchctl prison? Thanx in advance for any help, Johannes PS: If you're wondering why I don't use TimeMachine for Backups: We've used it till AppleFileServer started eating 100% CPU on the Server, rendering the Fileservice for the regular AFP Fileservice Clients unusable, while SSH at the same time had fullspeed and no problems. So splitting backup from fileservice was the deal for making fileservice useable again...

2 1

Fwd: Stray process with PGID equal to this dead job
by Johannes 28 Jul '09

28 Jul '09

OK, solved it by myself, did it the weird-apple way: A launchctl triggered backupfather.pl now creates Launchagents.plist for every child process including the calling arguments and triggers launchctl load/start for these creations... a lot of useless filewriting just for backgrounding processes for which a normal "&" would be enough as it seems but at least it works... Greets Johannes Am 27.07.2009 um 20:26 schrieb Johannes: > Sorry for reopening a thread that was already dealt with, but I ran > into a serious problem that I'm not able to workaround in any way. > > I have a perlscript (let's call it backupfather.pl) that calls a > second perlscript (backupchild.pl) 15 times for initiating rsync > over ssh backups from 15 different client-hosts. > > The callerscript knows how to deal with open processes (keep them > running for a designated time, kill them if the target host where it > fetches the backup from isn't reachable or the backup script is > overtime, don't launch the child script for a specific host if one > process like that is still running) > > Additionally it knows how to deal with the child processes of > backupchild.pl (rsync and ssh) building up pid and parent pid trees > and killing all involved before launching again with the same > arguments. > > So the processmanagement itself is clean. > > In order to start the backupchild.pl script 15 times I need to > background them. They may rund serveral hours so the backupfather.pl > has to get free to initiate the finished backups again after an > hour, not initiating the still running ones. > > I've tried several ways to get out of the launchctl processgroup > prison the backupfather.pl is running in. > > setpgrp doesn't work on Mac OS X (that way it would be possible to > let it run under the root's processgroups ID). > > forking and exiting the backupchild.pl didn't help eighter, nore did > creating 15 instances for each client backup and launching them as > necessary. As soon as it comes to backgrounding I'm stuck in: > > "Stray process with PGID equal to this dead job: PID _pidnumber_ > PPID _parentpidnumber_ perl" > > Any ideas how to get the backupchild.pl processes out of the > launchctl prison? > > Thanx in advance for any help, > Johannes > PS: If you're wondering why I don't use TimeMachine for Backups: > We've used it till AppleFileServer started eating 100% CPU on the > Server, rendering the Fileservice for the regular AFP Fileservice > Clients unusable, while SSH at the same time had fullspeed and no > problems. So splitting backup from fileservice was the deal for > making fileservice useable again...

1 0

Correct permissions for /Library/LaunchAgents
by Stephane Sudre 20 Jul '09

20 Jul '09

What should be the correct permissions for the /Library/LaunchAgents folder and the plist inside it? owner : group privileges ?

3 3

How to remove/unload anonymous job labels?
by Conrad Taylor 17 Jul '09

17 Jul '09

Hi, could someone tell me how to remove jobs which have labels like to the following: 353 - 0x10c8d0.mysqld 353 - 0x10b250.mysqld BTW, I have tried the following: sudo launchctl stop 0x10c8d0.mysqld sudo launchctl stop 0x10b250.mysqld However, they seem to persist after the above command has been invoked. -Conrad

2 3

Launchd and logging and users and groups
by Scott Haneda 15 Jul '09

15 Jul '09

Please be gentle, this is outside my comfort level in launchd. I have a spam proxy written in perl that needs to be started by launchd. When it starts, a few 100 lines of startup data is sent to whatever started it. If I start with with launchd, all that data will end up in /var/log/system.log I set the 'StandardOutPath' <key>StandardOutPath</key> <string>/dev/null</string> but I am not sure that is the correct way to deal with this. All the startup data is also sent to the proxy's log file, so to me, it seems redundant. However, I think the above StandardOutPath change may also mask away some important bits of launchd that may be desirable to be seen. All the files the proxy uses are owned by _assp:_assp, so I set: <key>UserName</key> <string>_assp</string> according to the docs, I need not se the group, it will auto set to the user. When I do that, launchd restarts repeatedly, and the logs that the perl file logs to aka: the proxy logs, will get this line repeated: Jul-14-09 23:58:03 Requested to switch to user/group '_assp/_assp' but cannot set effective uid to 0 -- quitting; uid is 504 If the proxy is automatically dropping into the correct user and group, then does that mean there is no need to run with the lunachd settings for UserName? Can I get some guidance on the best way to deal with this? Any suggestions on how this should be set up to be most ideal, is most appreciated. -- Scott * If you contact me off list replace talklists@ with scott@ *

2 3

Launching a process on demand?
by Conrad Taylor 07 Jul '09

07 Jul '09

Hi, I'm attempting to configure the MySQL launchd plist file to launch MySQL process only when needed. At this time, it's launched at boot/startup and it stays alive. At this time, the script looks as follows: BEGIN org.macports.mysql5.plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" " http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Debug</key> <false/> <key>Label</key> <string>org.macports.mysql5</string> <key>OnDemand</key> <false/> <key>ProgramArguments</key> <array> <string>/opt/local/bin/daemondo</string> <string>--label=mysql5</string> <string>--start-cmd</string> <string>/opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper</string> <string>start</string> <string>;</string> <string>--stop-cmd</string> <string>/opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper</string> <string>stop</string> <string>;</string> <string>--restart-cmd</string> <string>/opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper</string> <string>restart</string> <string>;</string> <string>--pid=none</string> </array> <key>RunAtLoad</key> <false/> </dict> </plist> END org.macports.mysql5.plist: I changed the above key/value pair to OnDemand/true. Now, the process doesn't start when I try to access it by doing the following: > mysql5 <RETURN> Is there a manual which clearly describes these key/value pairs? I guess I'm interested in the key/value pair, OnDemand, and when/how it works. -Conrad

3 3