Install and load a launch daemon without a reboot
What is considered the current best practice for installing and then running a launch daemon, while avoiding a reboot? I didn't see exactly what I was looking for in my list archive or found it in any documentation on installation packages. I have reviewed TN2083, specifically the "Starting a Daemon" section. That answers most of my question but it would be helpful to have confirmation. Besides the conditions listed in TN2083, I'd like my installer to behave well when installed to a disk other than the current startup volume. I need to target Mac OS X 10.5 and 10.6. It looks as if I'd need to test for the right conditions and then run launchctl to load the property list. Roughly -- not production code -- it looks like I'd need a postinstall and postupgrade script to do the following: # Test if the destination volume for the payload and the root volume path are the same if [ "$3" = "$4" ] ; then # Quick test to see if the script is run by root if [ `/usr/bin/whoami` = "root" ] ; then /bin/launchctl load "$3/Library/LaunchDaemons/com.vendor.launchdaemon.plist" fi fi exit 0 Is that the right approach? Thanks! -- Jeremy
On Jan 25, 2011, at 7:33 PM, Jeremy Reichman wrote:
What is considered the current best practice for installing and then running a launch daemon, while avoiding a reboot? I didn't see exactly what I was looking for in my list archive or found it in any documentation on installation packages.
I have reviewed TN2083, specifically the "Starting a Daemon" section. That answers most of my question but it would be helpful to have confirmation. Besides the conditions listed in TN2083, I'd like my installer to behave well when installed to a disk other than the current startup volume. I need to target Mac OS X 10.5 and 10.6.
It looks as if I'd need to test for the right conditions and then run launchctl to load the property list. Roughly -- not production code -- it looks like I'd need a postinstall and postupgrade script to do the following:
# Test if the destination volume for the payload and the root volume path are the same if [ "$3" = "$4" ] ; then # Quick test to see if the script is run by root if [ `/usr/bin/whoami` = "root" ] ; then /bin/launchctl load "$3/Library/LaunchDaemons/com.vendor.launchdaemon.plist" fi fi exit 0
Is that the right approach? Thanks!
By payload, do you mean an installation package payload? If so, then you need to require root/admin authentication in the installation package (to be able to install stuff in /Library/ LaunchDaemons/. And you don't need both a postinstall and postupgrade scripts. A postflight script is enough if you're using a bundle package. A postinstall script is OK if you are using a flat package. You don't need to use whoami. Just use sudo before /bin/launchctl.
On 25 Jan 2011, at 23:10, Iceberg-Dev wrote:
If so, then you need to require root/admin authentication in the installation package (to be able to install stuff in /Library/LaunchDaemons/.
One thing to be careful of is the distinction between EUID and RUID. IIRC the Installer, when yo escalated privileges, only sets the EUID, leaving the RUID set to that of the user who ran the Installer. This causes problem for launchctl, because launchctl uses the RUID to decide which launchd to talk to. You can use the chroot trick from my previous post to set both the EUID and RUID to 0. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On 1/26/2011 4:39 AM, "Quinn "The Eskimo!"" <eskimo1@apple.com> wrote:
If so, then you need to require root/admin authentication in the installation package (to be able to install stuff in /Library/LaunchDaemons/.
One thing to be careful of is the distinction between EUID and RUID. IIRC the Installer, when yo escalated privileges, only sets the EUID, leaving the RUID set to that of the user who ran the Installer. This causes problem for launchctl, because launchctl uses the RUID to decide which launchd to talk to. You can use the chroot trick from my previous post to set both the EUID and RUID to 0.
I was actually going to script this in Python but used the shell script snippet as a quick-and-dirty example. My Python if statement looks like this at the moment: import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here Quinn, did you mean the chroot idea in the "bootstrap" thread? If so, I'll either need a little more time to digest it, or just request a reboot with the installer. It sounds as if running the above Python in the context of an Installer postflight script would result in a no-op because of the RUID. Thanks! -- Jeremy
On 27 Jan 2011, at 20:47, Jeremy Reichman wrote:
Quinn, did you mean the chroot idea in the "bootstrap" thread?
Yes.
If so, I'll either need a little more time to digest it, or just request a reboot with the installer. It sounds as if running the above Python in the context of an Installer postflight script would result in a no-op because of the RUID.
If you have an EUID of 0 then the chroot trick lets your sync your RUID to that. Honestly, I'm /so/ not an expert in installers, either Apple's on third party, that your best bet is to test this for yourself. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On 1/28/2011 5:22 AM, "Quinn "The Eskimo!"" <eskimo1@apple.com> wrote:
Quinn, did you mean the chroot idea in the "bootstrap" thread?
Yes.
If so, I'll either need a little more time to digest it, or just request a reboot with the installer. It sounds as if running the above Python in the context of an Installer postflight script would result in a no-op because of the RUID.
If you have an EUID of 0 then the chroot trick lets your sync your RUID to that. Honestly, I'm /so/ not an expert in installers, either Apple's on third party, that your best bet is to test this for yourself.
Fair enough. I think I had such an expert weigh in on this thread already. If I might make a suggestion for the future of TN2083, sample code of an appropriate way to do this in an installer would be helpful. Especially for an installer that can be installed to any system disk, not just the current startup disk, so that such an installer could be used in the build process for deployment images (in System Image Utility or other similar workflows). -- Jeremy
On 28 Jan 2011, at 13:05, Jeremy Reichman wrote:
If I might make a suggestion for the future of TN2083 [...]
You should file this as a bug. <http://developer.apple.com/bugreporter/> We use Radar to track change requests for documentation in the same way we track change requests for the OS itself. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Fwiw, I submitted the request to update TN2083 with a sample installer postflight script that would load a LaunchDaemon after it was installed in the package payload. -- Jeremy
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it. Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up. If so, is there an acceptable method or process to load the agent? I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread. import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0. Thanks! -- Jeremy
/usr/bin/su $USER -c On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported. Please see: http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.html Thomas On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
In Lion, launchctl now has an asuser subcommand. Give it a shot: $ sudo launchctl asuser $DESIRED_UID bslist -- Damien Sorresso dsorresso@apple.com On Oct 12, 2011, at 2:29 PM, Thomas Clement wrote:
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported.
Please see: http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.html
Thomas
On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
That should be: $ sudo launchctl asuser $DESIRED_UID launchctl bslist -- Damien Sorresso dsorresso@apple.com On Oct 12, 2011, at 4:08 PM, Damien Sorresso wrote:
In Lion, launchctl now has an asuser subcommand. Give it a shot:
$ sudo launchctl asuser $DESIRED_UID bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 2:29 PM, Thomas Clement wrote:
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported.
Please see: http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.html
Thomas
On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
Very interesting. This command should really be documented in the launchctl man page. There is currently no word about it. On Oct 13, 2011, at 1:17 AM, Damien Sorresso wrote:
That should be:
$ sudo launchctl asuser $DESIRED_UID launchctl bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 4:08 PM, Damien Sorresso wrote:
In Lion, launchctl now has an asuser subcommand. Give it a shot:
$ sudo launchctl asuser $DESIRED_UID bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 2:29 PM, Thomas Clement wrote:
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported.
Please see: http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.html
Thomas
On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
On Oct 13, 2011, at 12:53 AM, Thomas Clement wrote:
Very interesting. This command should really be documented in the launchctl man page. There is currently no word about it.
Go ahead and file a bug. It is at least displayed when you do `launchctl asuser`. -- Damien Sorresso dsorresso@apple.com
On Oct 13, 2011, at 1:17 AM, Damien Sorresso wrote:
That should be:
$ sudo launchctl asuser $DESIRED_UID launchctl bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 4:08 PM, Damien Sorresso wrote:
In Lion, launchctl now has an asuser subcommand. Give it a shot:
$ sudo launchctl asuser $DESIRED_UID bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 2:29 PM, Thomas Clement wrote:
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported.
Please see: http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.html
Thomas
On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
On 13 oct. 2011, at 18:51, Damien Sorresso <dsorresso@apple.com> wrote:
On Oct 13, 2011, at 12:53 AM, Thomas Clement wrote:
Very interesting. This command should really be documented in the launchctl man page. There is currently no word about it.
Go ahead and file a bug.
It is at least displayed when you do `launchctl asuser`.
Yes but how would one do 'launchctl auser' if he doesn't know about the 'auser' command? I'm testing Lion since the first beta and I never heard of it before. Radar filed! Thanks, Thomas
On Oct 13, 2011, at 11:33 AM, Thomas CLEMENT wrote:
On 13 oct. 2011, at 18:51, Damien Sorresso <dsorresso@apple.com> wrote:
On Oct 13, 2011, at 12:53 AM, Thomas Clement wrote:
Very interesting. This command should really be documented in the launchctl man page. There is currently no word about it.
Go ahead and file a bug.
It is at least displayed when you do `launchctl asuser`.
Yes but how would one do 'launchctl auser' if he doesn't know about the 'auser' command? I'm testing Lion since the first beta and I never heard of it before.
Radar filed!
Er, that was supposed to be `launchctl help`. Sorry! -- Damien Sorresso dsorresso@apple.com
On Oct 13, 2011, at 9:49 PM, Damien Sorresso wrote:
On Oct 13, 2011, at 11:33 AM, Thomas CLEMENT wrote:
On 13 oct. 2011, at 18:51, Damien Sorresso <dsorresso@apple.com> wrote:
On Oct 13, 2011, at 12:53 AM, Thomas Clement wrote:
Very interesting. This command should really be documented in the launchctl man page. There is currently no word about it.
Go ahead and file a bug.
It is at least displayed when you do `launchctl asuser`.
Yes but how would one do 'launchctl asuser' if he doesn't know about the 'asuser' command? I'm testing Lion since the first beta and I never heard of it before.
Radar filed!
Er, that was supposed to be `launchctl help`. Sorry!
Ah ok :) Thanks! Thomas
Thanks for the replies. I'm looking for clarification, though. It looks like it is possible to launch in the user's context. Prior to the new launchctl feature in Lion, is it _appropriate_ to start a LaunchAgent in the context of the current user as part of an _Apple package installer script_? I ask for myself, and also because I see vendors doing this on their own. Especially with the link back to Quinn's answer, it seems to be preferable to request a restart to load the agent ... unless a) you're running on at least Lion and b) your target disk is also at least Lion. I'm coming from a sysadmin background, so I tend to think that having an installer script do anything in the user context is a recipe for problems. There are so many ways that an installer can be run (especially when you get to managed environments). Installer scripts often make assumptions that their parent installer is being run in only one of them. Thanks! -- Jeremy On 10/12/2011 7:17 PM, "Damien Sorresso" <dsorresso@apple.com> wrote:
That should be:
$ sudo launchctl asuser $DESIRED_UID launchctl bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 4:08 PM, Damien Sorresso wrote:
In Lion, launchctl now has an asuser subcommand. Give it a shot:
$ sudo launchctl asuser $DESIRED_UID bslist -- Damien Sorresso dsorresso@apple.com
On Oct 12, 2011, at 2:29 PM, Thomas Clement wrote:
Not that simple. You must switch into the appropriate user context which turns to be quiet complicated and unsupported.
Please see:
http://lists.macosforge.org/pipermail/launchd-dev/2011-January/000890.ht ml
Thomas
On Oct 12, 2011, at 11:23 PM, Stephane Sudre wrote:
/usr/bin/su $USER -c
On Wed, Oct 12, 2011 at 9:01 AM, Jeremy Reichman <jaharmi@jaharmi.com> wrote:
I'm resurrecting an old thread -- but it was my thread, and I have a slightly new spin on it.
Is it appropriate to start a LaunchAgent for the current user (with LimitLoadToSessionType: Aqua) via a script (such as post{install,upgrade}) in an installer? I don't remember this being covered in TN2083, and my quick re-review of the tech note didn't turn anything up.
If so, is there an acceptable method or process to load the agent?
I am able to load a LaunchDaemon via an installer script, and have done so via the recommendation of checking to make sure EUID and RUID are 0. My Python code from earlier in the thread.
import posix if posix.getuid() and posix.geteuid() == 0: # launchctl here
At the very least, I'd expect you'd need to find the current user and load the agent in that account's context even though the installer and its scripts are running with EUID/RUID 0.
Thanks!
launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
Isn't this a solution to launch the agents for all users' sessions instead of just for the current one?
I tested, and with my installer -- which is set to require RootAuthorization -- the following Python snippet in a postflight script: if real_uid == 0 and effective_uid == 0: ... does succeed. Both the UID and EUID are 0. I also see that the launchdaemon that I was trying to load is, in fact, loaded afterwards (when running launchctl with sudo). Although I'm going to have to confirm that on a clean system, so take that result with a grain of salt. -- Jeremy
On 1/25/2011 6:10 PM, "Iceberg-Dev" <dev.iceberg@gmail.com> wrote:
By payload, do you mean an installation package payload?
If so, then you need to require root/admin authentication in the installation package (to be able to install stuff in /Library/ LaunchDaemons/.
And you don't need both a postinstall and postupgrade scripts. A postflight script is enough if you're using a bundle package. A postinstall script is OK if you are using a flat package.
You don't need to use whoami. Just use sudo before /bin/launchctl.
To clarify, I did mean the payload. In my case, I'm using The Luggage to build the package, so the authorization defaults it sets work. Good point about postflight, as I will be creating a bundle package for the time being.
participants (7)
-
Damien Sorresso
-
Iceberg-Dev
-
Jeremy Reichman
-
Quinn "The Eskimo!"
-
Stephane Sudre
-
Thomas Clement
-
Thomas CLEMENT