Welcome, I was invited to bring this thread here by Quinn. My apologies if you've seen bits and pieced of this thread before; it's traveled around the Cocoa, Carbon, and MacNetworkProg lists before landing here. I'm developing a backup and document archiving solution (<http://www.qrecall.com/> -- not an ad, just for reference). The program provides "actions" that can be scheduled to run at regular intervals or in response to certain events. These actions should be performed whether the user is logged in or out. In fact, actions can be scheduled to run only when the user is logged out or because the user logged out. There is a scheduler process which is responsible for managing all of this. The scheduler works on behalf of a single user. (Other users may have their own schedule/scheduler.) For security, the scheduler runs under the UID of that user. So, what I have is a process that - Needs to start up when the system boots and runs until the system shuts down, independent of whether the user is logged in or not. - Runs as a single user (not as root) without any special privileges. - Can be installed and removed without requiring administrative authorization. In effect, I need a "User Daemon" -- a class of process that launchd does not provide. I was simulating this (pretty well) using crontab. The crontab will allow non-admin users to install a cronjob that runs periodically and independently of their login session. Unfortunately, recent versions of Tiger and Leopard have become downright hostile towards user cronjobs, sending them SIGKILL signals whenever the user is logged out (without even the courtesy of a SIGTERM first!). I'm now simulating this by installing a system-wide daemon for each user (/Library/LaunchDaemons/QRecallScheduler501.plist, .../QRecallScheduler502.plist, etc.). Each daemon is configured to run as that user (via the UserName property). But this requires administrative privileges to install/uninstall a non-privileged process. Beyond being annoying, it limits the usefulness of the application for non-admin users. And in the pit of my stomach, I feel that it presents a security hole. I'm basically just throwing this out to the launchd team for comments, which might result in filing a feature request. I also understand some of the potential problems in implementing user daemons. (For example, the logical place to place a user daemon configuration file would be in ~/Library/LaunchDaemons, but that obviously won't work with FileVault or users who mount their home folder over a network.) However, there are also potential solutions to some of these and there's also the principle that one shouldn't necessarily eliminate a feature just because 0.1% of the users can't use it. ;) Any thoughts? -- James Bucanek