From jaharmi at jaharmi.com Thu Oct 4 05:59:27 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Thu Oct 4 05:59:14 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: <68DB3C2D-D33B-452A-BE4A-99D36F6A89A5@apple.com> Message-ID: I'm also having a problem with a LaunchAgent in the local domain. I'm trying to install it to /Library/LaunchAgents via a package installer on Mac OS X 10.4.10 (PowerPC on my test system). It installs and appears loaded via Lingon, but even a logout and login does not cause it to run. I've also tried to load and start it at the command line via launchctl, and the specified script does not run ... at least not in a reasonable amount of time (30 sec). I don't know if this is because I've specified LowPriorityIO or not, but toggling that setting on/off hasn't seemed to make a difference yet. I'm just copying one file from /Library to ~/Library. The script itself runs without error if I execute it directly without the LaunchAgent. However, I'd like to be able to execute it for each user -- as the user -- as they log in, and I don't want to set up and use a LoginHook instead. I also want the installer to make sure the LaunchAgent is set up and running, and preferably run the job once for that current user. While I can do that with a postinstall script in the package installer that calls the LaunchAgent's target script, I'd really like to make sure that the LA is ready to go. I feel like I'm missing something. -- Jeremy From zarzycki at apple.com Thu Oct 4 10:41:48 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Thu Oct 4 11:06:26 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: References: Message-ID: LaunchAgents are busted in Tiger, but fixed in Leopard. Sorry! davez On Oct 4, 2007, at 5:59 AM, Jeremy Reichman wrote: > I'm also having a problem with a LaunchAgent in the local domain. > > I'm trying to install it to /Library/LaunchAgents via a package > installer on > Mac OS X 10.4.10 (PowerPC on my test system). It installs and > appears loaded > via Lingon, but even a logout and login does not cause it to run. > > I've also tried to load and start it at the command line via > launchctl, and > the specified script does not run ... at least not in a reasonable > amount of > time (30 sec). I don't know if this is because I've specified > LowPriorityIO > or not, but toggling that setting on/off hasn't seemed to make a > difference > yet. I'm just copying one file from /Library to ~/Library. > > The script itself runs without error if I execute it directly > without the > LaunchAgent. However, I'd like to be able to execute it for each > user -- as > the user -- as they log in, and I don't want to set up and use a > LoginHook > instead. > > I also want the installer to make sure the LaunchAgent is set up and > running, and preferably run the job once for that current user. > While I can > do that with a postinstall script in the package installer that > calls the > LaunchAgent's target script, I'd really like to make sure that the > LA is > ready to go. > > I feel like I'm missing something. > > > -- > Jeremy > > > _______________________________________________ > launchd-dev mailing list > launchd-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/launchd-dev From kcrwfrd at gmail.com Mon Oct 8 20:38:20 2007 From: kcrwfrd at gmail.com (Kyle Crawford) Date: Mon Oct 8 20:37:48 2007 Subject: [launchd-dev] GUI app before loginwindow post Tiger Message-ID: <4c135e8c0710082038y3f5d31fatd74a5efc95e7e1da@mail.gmail.com> What is the recommended way to run a GUI app before loginwindow post Tiger? In Panther I could set dependencies in StartupItems In Tiger I called my script from rc.local so it would run before loginwindow. I see that rc.local is still supposed to work post Tiger, but it does not seem to be able to force it to run before loginwindow and seems to be lumped in with StartupItems. Also, perhaps a separate issue is that I get a message that untrusted apps can not attach to or launch WindowServer on demand before loginwindow. Is this somehow related to LimitLoadToSessionType? I am a scripter/sysadmin attempting to run iHook to display progress of a script before a user can login. I do plan on doing more on demand, but some tasks like installing software that requires a reboot don't make sense post-login since the user would be interrupted and told to reboot soon after they logged in anyway. Kyle Crawford -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071008/f6e9b256/attachment.html From eskimo1 at apple.com Tue Oct 9 02:13:34 2007 From: eskimo1 at apple.com (Quinn) Date: Tue Oct 9 02:15:05 2007 Subject: [launchd-dev] GUI app before loginwindow post Tiger In-Reply-To: <4c135e8c0710082038y3f5d31fatd74a5efc95e7e1da@mail.gmail.com> References: <4c135e8c0710082038y3f5d31fatd74a5efc95e7e1da@mail.gmail.com> Message-ID: At 23:38 -0400 8/10/07, Kyle Crawford wrote: >What is the recommended way to run a GUI app before loginwindow post Tiger? Unfortunately, the only post-Tiger operating system announced is Leopard, and we're not allowed to discuss Leopard on a public mailing list prior to its release. Sorry. At this point the only way to get answers to Leopard development questions is via a DTS Tech Support Incident. Share and Enjoy -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From mahansen2573 at winona.edu Mon Oct 15 11:59:23 2007 From: mahansen2573 at winona.edu (Matthew Hansen) Date: Mon Oct 15 11:59:05 2007 Subject: [launchd-dev] Environment Variables and LimitLoadToSessionType? Message-ID: Question about environment variables under launchd (10.4)... Our launchd item needs to run as root and theres really no way around that, we are small, low level admin maintenance on many machines... So far I've determined the best location to be /Library/ LauchdDaemons...even though I would prefer running only after all system services are up and running, and most likely after login. Maintenance items would mostly likely replacing expired software license keys, auto-updating of "in-house" custom applications, and Active Directory password expiration notifications. Is this something that can be done with "LimitLoadToSessionType" in Tiger, or is this a Leopard only feature? I haven't been able to find documentation on the session types...? Our main question relating to this what is the best way to get the shortname of the logged in user in the launchd item running as root? again launched from /Library/LauchdDaemons, this is for running lookups on the user, for group memberships, setting permissions, and notifications... Previously we have always used either the system $USER variable or $SUDO_USER when executing as root to get the shortname of the user to initiated the sudo command. Neither of these become useful after loading the job into launchd because of the job being run as root, initiated by launchd. Thanks, Matt From zarzycki at apple.com Mon Oct 15 12:42:46 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Mon Oct 15 12:42:30 2007 Subject: [launchd-dev] Environment Variables and LimitLoadToSessionType? In-Reply-To: References: Message-ID: On Oct 15, 2007, at 11:59 AM, Matthew Hansen wrote: > Question about environment variables under launchd (10.4)... > > Our launchd item needs to run as root and theres really no way > around that, we are small, low level admin maintenance on many > machines... > So far I've determined the best location to be /Library/ > LauchdDaemons...even though I would prefer running only after all > system services are up and running, and most likely after login. The "milestone" you're want to depend on no longer exists as far as Apple is concerned. Please use our frameworks (a.k.a. shared libraries) to monitor the events that you're interested in. Thanks! > Maintenance items would mostly likely replacing expired software > license keys, auto-updating of "in-house" custom applications, and > Active Directory password expiration notifications. > Is this something that can be done with "LimitLoadToSessionType" in > Tiger, or is this a Leopard only feature? LimitLoadToSessionType is a Leopard only feature. > I haven't been able to find documentation on the session types...? At the moment, they're documented in Leopard under the launchctl man page. > Our main question relating to this what is the best way to get the > shortname of the logged in user in the launchd item running as root? > again launched from /Library/LauchdDaemons, this is for running > lookups on the user, for group memberships, setting permissions, and > notifications... > Previously we have always used either the system $USER variable or > $SUDO_USER when executing as root to get the shortname of the user > to initiated the sudo command. > Neither of these become useful after loading the job into launchd > because of the job being run as root, initiated by launchd. Hmm... It isn't really clear to us what you want. Do you want to run as root? Or as the user who is logged in? If think you want both, can you please explain why? Thanks! davez From kilian_s at gmx.de Mon Oct 29 00:09:09 2007 From: kilian_s at gmx.de (ksprotte) Date: Mon Oct 29 00:07:53 2007 Subject: [launchd-dev] Disabled in com.apple.periodic-daily.plist Message-ID: <13462465.post@talk.nabble.com> Hi, I have seen a lot of talk about using launchd to run the periodic jobs. However, I could not find a comment about the Disabled flag. It seems that in the com.apple.periodic-daily.plist the Disabled flag is true by default. I am not sure what this actually means. Could someone explain, please? Thanks, Kilian -- View this message in context: http://www.nabble.com/Disabled-in-com.apple.periodic-daily.plist-tf4709986.html#a13462465 Sent from the Launchd mailing list archive at Nabble.com. From kvv at apple.com Mon Oct 29 00:23:37 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Mon Oct 29 00:22:26 2007 Subject: [launchd-dev] Disabled in com.apple.periodic-daily.plist In-Reply-To: <13462465.post@talk.nabble.com> References: <13462465.post@talk.nabble.com> Message-ID: On Oct 29, 2007, at 12:09 AM, ksprotte wrote: > I have seen a lot of talk about using launchd to run the periodic > jobs. > However, I could not find a comment about the Disabled flag. It seems > that in the com.apple.periodic-daily.plist the Disabled flag is true > by > default. com.apple.periodic-daily.plist does not contain the Disabled key on my Leopard system. Which system (`sw_vers -buildVersion`) are you seeing this on? > I am not sure what this actually means. Could someone explain, please? If a property list contains the Disabled key with a value of true, then launchctl(1) will not load the job at boot (and the job's label will not be listed in `sudo launchctl list`). - Kevin From jaharmi at jaharmi.com Mon Oct 29 11:55:23 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Mon Oct 29 11:54:05 2007 Subject: [launchd-dev] Run job when network configuration changes Message-ID: I'm looking at the new KeepAlive section in the launchd.plist man page, specifically at the NetworkStatus item. Could this be used to run a job _once_ whenever the system's network configuration changes ... a laptop moves from wired to wireless, or moves from work to home, or the like? But run the same job each time the network config changes? I'm not quite sure from the description. I used to be able to add an item to Kicker.xml for SystemConfiguration, but I hear that's no longer an option. I haven't checked for it yet, myself, though. Even so, this was not optimal because my edits in Kicker.xml might have overwritten by Apple in a future software update. Writing my own daemon is also not an option; this is purely for systems administration purposes and I'd like to only _add_ a launchd plist and _add_ a script to the system if that's possible. This ability to only add on, not edit or replace existing config files, is one attraction of launchd at the systems administration level. Thanks! -- Jeremy From jaharmi at jaharmi.com Mon Oct 29 11:58:05 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Mon Oct 29 11:56:49 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: Message-ID: On 10/4/07 1:41 PM, "Dave Zarzycki" wrote: > LaunchAgents are busted in Tiger, but fixed in Leopard. So now, with Leopard, LaunchAgents in /Library/LaunchAgents will run at login for each user, as the user (by default), and without having to restart the computer between each user login session? -- Jeremy From eskimo1 at apple.com Mon Oct 29 11:47:03 2007 From: eskimo1 at apple.com (Quinn) Date: Mon Oct 29 12:44:57 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: References: Message-ID: At 14:58 -0400 29/10/07, Jeremy Reichman wrote: >So now, with Leopard, LaunchAgents in /Library/LaunchAgents will run at >login for each user, as the user [...], and without having to restart >the computer between each user login session? Yes. The only significant gotcha that I can think of relates to installing and upgrading. Except in the simple case (where you have one user logged in and your installer/upgrader is running in that user's context), you run into problems with the install/upgrade process. There's no built in way for you to tell all per-user launchd's on the system that a new property list has been installed (or that an old one has been upgraded). Thus, you can get into situations where one user is running version X of your agent and another is running version X+1. Or one user doesn't have the agent installed and another does. There's no really good way around this right now (although there are plenty of hackish ways). Just for the record, we're tracking this as . >as the user (by default) The "(by default)" indicates some confusion about how agents work. An agent is always launched by a per-user launchd, and that per-user launchd is always running with its EUID and RUID set to that of the user on whose behalf it's working. Thus, there's no "by default" about it. An agent will always run as that user and there's no way around that (other than by doing something silly like making your agent setuid root). The UserName and GroupName properties in an agent's plist are ignored (as they were on 10.4.x). I've rolled all of this info into a new Technote 2083 "Daemons and Agents" that scheduled to be published in the next couple of weeks. Watch the skies! (actually, :-) S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From eskimo1 at apple.com Mon Oct 29 12:43:20 2007 From: eskimo1 at apple.com (Quinn) Date: Mon Oct 29 13:41:14 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: At 14:55 -0400 29/10/07, Jeremy Reichman wrote: >Could this be used to run a job _once_ whenever the system's network >configuration changes ... a laptop moves from wired to wireless, or moves >from work to home, or the like? But run the same job each time the network >config changes? I'm not quite sure from the description. AFAICT this won't do what you want. This option is triggered when the system transitions from zero IP interface to not zero IP interfaces, and vice versa. It is not triggered, for example, when you transition from one IP address to a different one. S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From jaharmi at jaharmi.com Mon Oct 29 17:48:10 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Mon Oct 29 17:46:50 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: References: Message-ID: <1193705290.28520.1218500239@webmail.messagingengine.com> On Mon, 29 Oct 2007 19:47:03 +0100, "Quinn" said: > At 14:58 -0400 29/10/07, Jeremy Reichman wrote: > >So now, with Leopard, LaunchAgents in /Library/LaunchAgents will run at > >login for each user, as the user [...], and without having to restart > >the computer between each user login session? > > Yes. The only significant gotcha that I can think of relates to > installing and upgrading. Except in the simple case (where you have > one user logged in and your installer/upgrader is running in that > user's context), you run into problems with the install/upgrade > process. There's no built in way for you to tell all per-user > launchd's on the system that a new property list has been installed > (or that an old one has been upgraded). Thus, you can get into > situations where one user is running version X of your agent and > another is running version X+1. Or one user doesn't have the agent > installed and another does. There's no really good way around this > right now (although there are plenty of hackish ways). > > Just for the record, we're tracking this as . Okay, good to know. I'm not certain I will run into this situation without having a logout or reboot close by ... and I assume a logout for all users or a system reboot will resolve the situation. > >as the user (by default) > > The "(by default)" indicates some confusion about how agents work. > An agent is always launched by a per-user launchd, and that per-user > launchd is always running with its EUID and RUID set to that of the > user on whose behalf it's working. Thus, there's no "by default" > about it. An agent will always run as that user and there's no way > around that (other than by doing something silly like making your > agent setuid root). The UserName and GroupName properties in an > agent's plist are ignored (as they were on 10.4.x). > > I've rolled all of this info into a new Technote 2083 "Daemons and > Agents" that scheduled to be published in the next couple of weeks. > Watch the skies! (actually, :-) I'm looking forward to it! I hope it lays out things a little more clearly for sys admins, because I know quite a few who've given up on launchd. The "by default" confusion on my part is simply that I know it is possible to put it in the plist but I'd never personally tried to set it to some other value in a LaunchAgent. So, I was covering my bases there, even though it didn't make sense to me for a LaunchAgent to try to switch to another user's context. It's good to know that the attempt will be ignored. I'd been banging my head against the LaunchAgent wall enough in Tiger, just trying to get them to work as I expected from the man page. I'm glad to see it's worth trying again. -- Jeremy From jaharmi at jaharmi.com Mon Oct 29 18:00:30 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Mon Oct 29 17:59:12 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <1193706030.31051.1218500651@webmail.messagingengine.com> On Mon, 29 Oct 2007 20:43:20 +0100, "Quinn" said: > At 14:55 -0400 29/10/07, Jeremy Reichman wrote: > >Could this be used to run a job _once_ whenever the system's network > >configuration changes ... a laptop moves from wired to wireless, or moves > >from work to home, or the like? But run the same job each time the network > >config changes? I'm not quite sure from the description. > > AFAICT this won't do what you want. This option is triggered when > the system transitions from zero IP interface to not zero IP > interfaces, and vice versa. It is not triggered, for example, when > you transition from one IP address to a different one. Is there a way to run such a job with launchd now? If Kicker.xml from SystemConfiguration is gone, as I've heard, I'd like to find an alternative. I have had at least one specific need for it in the past. It always would have been cleaner, to my way of thinking, to have launchd let me watch for network change events directly and then trigger my job. This feels like a good addition if it's not there, now that launchd can trigger a job during the transition from zero to some interfaces and vice versa. The missing piece appears to be the transition from one IP to another. If that's still not possible in launchd I'd be happy to file an enhancement request, unless there's a specific reason this type of trigger should be avoided. Thanks! -- Jeremy From eskimo1 at apple.com Tue Oct 30 02:09:43 2007 From: eskimo1 at apple.com (Quinn) Date: Tue Oct 30 03:16:28 2007 Subject: [launchd-dev] Starting launch agents In-Reply-To: <1193705290.28520.1218500239@webmail.messagingengine.com> References: <1193705290.28520.1218500239@webmail.messagingengine.com> Message-ID: At 20:48 -0400 29/10/07, Jeremy Reichman wrote: >I assume a logout for all users or a system reboot will resolve the situation. That's correct. >I'm looking forward to it! I hope it lays out things a little more >clearly for sys admins, because I know quite a few who've given up on >launchd. Alas, not really. My mandate is specifically to assist developers. However, like the current TN2083, it does explain the underlying architecture, and you can use that knowledge to make sensible decisions about how to deploy things. S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware