- launchd-dev - lists.macosforge.org

Obtaining information about a process from launchd
by Chris Stevens 31 Jul '08

31 Jul '08

Hi all, Sorry for the somewhat basic question, I am writing a server in python that I have registered with launchd. I am using a preference pane to control the service (using "launchctl start/stop"), but I would like the preference pane to know if the service is actually running. Because it is a python script, the process shows up just as 'Python', so tracking the process using NSWorkspace launchedApplications (actually I just read this may not work anyway) would not work if the user happens to be using other python scripts. Is there a way to get the status of my process from launchd? Since launchd is controlling the whole show, I thought there must be some method to find out if my python script is actually running, stopped, dead, whatever. Thankyou! Chris.

2 1

Re: [launchd-dev] run once and then vaporize
by Blake Garner 24 Jul '08

24 Jul '08

Thanks Quinn! Your explanation was informative and solved my problem. I attempted to have the script remove the .plist before but It was failing due to permission problems. After correcting the permissions on my script it's working! blake On Thu, Jul 24, 2008 at 7:43 AM, Quinn <eskimo1(a)apple.com> wrote: > At 19:15 -0700 23/7/08, Blake Garner wrote: >>My test script currently just echo's some text into system.log and >>exits. The script runs but the launchd item fails to unload or remove >>itself. > > That's because launchd does not pass the ProgramArguments to a shell; > rather, it invokes fork/exec (maybe even posix_spawn these days) with > those arguments. So the ";" isn't considered special. If you modify > your "runonce.sh" to print all of its arguments, you'll find that > it's getting a whole bunch of extra ones (-: > > I don't think this ProgramArguments approach is going to work. You > will have to unload the job from your script. > > Alternatively, don't unload the job. Once a job is loaded, it > doesn't depend on the plist file, so removing the plist file out from > underneath launchd won't cause you any problems. The job will > continue to exist in launchd (until the system restarts) but it won't > get run against unless someone specifically invokes it. > > S+E > -- > Quinn "The Eskimo!" <http://www.apple.com/developer/> > Apple Developer Relations, Developer Technical Support, Core OS/Hardware > _______________________________________________ > launchd-dev mailing list > launchd-dev(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev >

1 0

run once and then vaporize
by Blake Garner 24 Jul '08

24 Jul '08

I'm hoping that an elegant solution exists for launchd to kick off a script on boot as root and then unload and remove itself. I understand that login hooks and startup items may be simpler but I would prefer to use a launchd plist as it fits better with our automation system. This is what I have right now.. <?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>Label</key> <string>runonce</string> <key>ProgramArguments</key> <array> <string>/Library/Scripts/runonce.sh</string> <string>;</string> <string>/bin/launchctl</string> <string>unload</string> <string>-w</string> <string>/Library/LaunchDaemons/runonce.plist</string> <string>;</string> <string>/usr/bin/rm</string> <string>/Library/LaunchDaemons/runonce.plist</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> My test script currently just echo's some text into system.log and exits. The script runs but the launchd item fails to unload or remove itself. Ideally I would like to keep the removal function in the launchd item. Suggestions and links to similar examples are welcome. Thanks, Blake

3 2

XCode 3.0. Unresolved externals
by Vyacheslav Karamov 21 Jul '08

21 Jul '08

Hi All! I've made launchd-enabled daemon with XCode 2.4, but with XCode 3.0 I get some unresolved externals. Should I add any framework to my project?

2 4

Re: [launchd-dev] launchd and watchpath
by Don Montalvo 18 Jul '08

18 Jul '08

Of course I meant "Instead of ACL's" -Don Date: Sun, 08 Jun 2008 10:07:33 -0400 > From: Don Montalvo <donmontalvo(a)mac.com> > Subject: [launchd-dev] launchd and watchpath > To: launchd-dev(a)lists.macosforge.org > Message-ID: <41D7B3A5-6EAC-4647-8ACB-D2378ABD170C(a)mac.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > We would like to set up a folder on our Macs that forces incoming > files/folders to inherit permissions. Instead of ADL's, we'd like to > use launchd (and watchpath). I'm not familiar with launchd, so I think > this would be a good way to get my feet wet. > > The shared folder would be: > > /Users/Shared/WORK > > Each user would have an alias to it on their Desktop (created via > logout hook): > > ~/Desktop/WORK > > How can I set up launchd to watch this folder and ensure the contents > are always set to 777? I don't have experience with launchd. I toyed > with it in early Tiger days but there were issues with user launchd so > I gave it up and stuck with cron. I understand launchd works as > advertised on Leopard. Hoping it can help with this little project. :) > > Thanks, > Don

2 3

OnDemand USB Software
by Mike Fischer 11 Jul '08

11 Jul '08

Hi! I'm trying to evaluate if it is feasable to have an on-demand daemon depend on the presence of a certain usb device. I.e. I'd like the daemon to launch when the USB-device is plugged in. So far, looking at tn2083 and the man pages, I don't see any way to have a depency on USB or IOKit in general. Am I missing something here? If there is no direct support would it make sense to have a very small, lightweight daemon always running that registers for IOKit IOServiceAddMatchingNotification notifications and creates a semaphore file that can be used to trigger the launch of the real daemon for example? BTW: This would be mainly for Leopard, although Tiger would be interesting too. Thanks! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses.

3 2

Re: [launchd-dev] noob question you all can answer (Don Montalvo)
by Nehemiah Dacres 11 Jul '08

11 Jul '08

It is a simple manor of stopping you from shooting your self in the foot. if you log in as root, there will be no warnings to you from doing such things as deleting core frameworks and the like. (this is from experience) Also, not running as an administrative user to do everyday tasks like email would keep you from being infected with trojans (there exist dangerous mac malware!) without at least SOME input from you. enabling the root password has been easiest way for me to use macports but thats me. -- "lalalalala! it's not broken because I can use it" http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&…

1 0

Re: [launchd-dev] noob question you all can answer
by Don Montalvo 10 Jul '08

10 Jul '08

Shawn Erickson <shawnce(a)gmail.com> wrote: > You should never need to enable the root account on Mac OS X. At the sake of starting another UNIX holy war......why not? Don

2 2

noob question you all can answer
by Nathan Wan 08 Jul '08

08 Jul '08

Hi all I am trying to write a daemon, but I cannot seem to get it to load at boot time. On the system log, it says something to the effect of "dubious file permissions". I asked by accident on the cocoa mailing list, it they say it's because my plist in /Library/LaunchDaemon is not owned by the root with 644 permissions; but I have sudo'd, chmod'ed, chown'd to no avail. I cannot change ownership of the file to root. If this is the real problem, how do I fix it? If not, how do I fix it? Thanks Nathan

5 7

automatic job removal
by John Maisey 26 Jun '08

26 Jun '08

Hi, I have an application that as part of its activation installs a launch agent in the current users ~/Library/LaunchAgents/. The launch agent watches a folder path and when required launches the UNIX command open to locate and launch a background application within the original application package. This all seems to be working fine. If a user chooses to stop using the application they are asked to deactivate it by opening it and pressing a 'deactivate' button. The main reason for this is to deactivate the associated launchd job. However some users of the app. are deleting the application package without doing this. This leaves the user with an orphaned launchd job calling 'open' to find an application that is not on the user's system. Open returns an error and the launchd job returns 'code 1'. This will repeat on a regular basis. I am looking for advice as to how best avoid this eventuality. My initial thought was to host the launchd.plist inside the application package and soft link to it. This won't help because the WatchPath is inside the users account. I tried using a tilde to replace the user's folder path in the WatchPath, but evidently this does not get expanded by launchd. Another option could be to create a plist per user within the application package and soft link to it from ~/Library/LaunchAgents/. This doesn't seem like much of a solution to me. Can you suggest a better solution? Is there a reason for launchd not to expand tilde on launch agent paths? Thanks for your time. John (I am reading in digest mode, so please cc my email address)

2 2