Lauchagents and plist help

[Krytos]

Hello,

I'm trying to use launchagents to run a login script for every user -- on every login to a machine.

So far I've created the plist, and the script (it just creates a link to that users home directory on the desktop)

What I'm having trouble with is which launchagents folder should it go in and what permissions are necessary to run the plist at EVERY login event? /System/Library/LaunchAgents or /Library/LaunchAgents Or is there some where else?

Also, I've given everyone execute permissions to the Script -- but what permissions are needed on the .plist?

Once I've got it all correct, I'll be using this method to distribute it: https://jamfnation.jamfsoftware.com/discussion.html?id=15401

[mm2270]

You should never put anything in /System/Library/LaunchAgents/ That is strictly for OS X, not anything custom made. And in fact, it would impossible to put anything there under El Capitan due to that location being protected by SIP.

That leaves /Library/LaunchAgents/ and ~/Library/LaunchAgents/ The difference between them is, /Library/LaunchAgents/ already exists by default on a normal OS X install, and is considered a global LaunchAgent directory. That means it becomes active for any user that logs in. ~/Library/LaunchAgents/ is only for the account that ~ references, so meaning a specific home folder. It will only activate for that user, so these are considered personal LaunchAgents.
The folder won't exist initially under a new account. Though it is often created by installers, like some Adobe installations for example.

As for permissions, launchd plists, regardless if they are LaunchAgents or LaunchDaemons, are 644 POSIX and root:wheel as owner:group.
In case its unclear, 644 means:

root: Read and Write wheel: Read Everyone: Read

All that being said, in order to ensure your plist works, I recommend using an application to create it, at least at first. Something like LaunchControl or Lingon for example.

Hope the above helps.

[Krytos]

@mm2270

Thanks for the clarification!! thats really helpful.

COuld you check my plist? I created it on http://launched.zerowidth.com/ And I'm not certain it will run for every user, at every login.
to load the plist i used ~#: sudo launchctl load -w com.zerowidth.launched.loginscript.plist

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.zerowidth.launched.loginscript</string> <key>ProgramArguments</key> <array> <string>/var/Scripts/LoginScript</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>

[sean]

With this LaunchAgent set to RunAtLoad, the act of logging in is the trigger to load the agent, not running launchctl per se. By running it as described, you have loaded it as root and therefore it will run under root's environment. If you wish to get it to run as soon as you deploy (and users are already logged in) this is a harder task.

As to whether it will run or not, as long as you have followed @mm2270 's instructions, that will be decided by the permissions of the LoginScript and parent folders. These will need to be accessible and executable by the users running the script.

It will then depend on the commands you have used inside the script. Some commands are limited to administrative privileges. Eg.

$ whoami
auser
$ systemsetup -getdate
You need administrator access to run this tool... exiting!

[Krytos]

@sean

This is a lab environment -- so I want the script to run at every users login, not just root.
The script has execute writes for all users, but now my question is, how do i install a launch agent to run for every user? not just root?

Thanks!

[mm2270]

@Krytos As has already been mentioned, simply install it into /Library/LaunchAgents/ and it will run on any user login. That's a global LaunchAgents directory so it affects everyone, but only who is logging in, not inactive accounts.

As @sean mentioned, don't load the LaunchAgent plist with a root command or it becomes a root process and will therefore not work as a LaunchAgent It effectively becomes a LaunchDaemon despite the folder its running from.

If you only need to install it and then have it load naturally at login, just create a pkg that will place it in /Library/LaunchAgents/ and it will begin working on the next user login.
If you need to install it and activate it for the current user at the same time, that's a different story, and the method will depend on the target OS.

[Krytos]

@mm2270 Thank you!

What I guess I'm confused about is

don't load the LaunchAgent plist with a root command or it becomes a root process and will therefore not work as a LaunchAgent It effectively becomes a LaunchDaemon despite the folder its running from.

does this mean I cannot use sudo launchctl load -w login.plist ?? all I need to do is just copy the plist to the right place and walk away?

[mm2270]

does this mean I cannot use sudo launchctl load -w login.plist ?? all I need to do is just copy the plist to the right place and walk away?

Correct. You can't load a user level launch agent as root (sudo launchctl) or its effectively no longer a LaunchAgent. At least not until a log out or reboot. Just drop it into place and the next time someone logs in it becomes active. launchctl is only used for listing, activating, deactivating and doing some other operations on launchd jobs outside of the normal way they run, which is typically at boot up or login, or through some other trigger, like a WatchPath.

[Krytos]

@mm2270

so on the computer that I DID load it. Should I just unload it using launchctl unload ?

[mm2270]

I don't know. Depends on what its doing. If its really only supposed to be running the script for the logged in user, then I would unload it and let it load naturally on next login.

As I mentioned, if you need this to be loaded for the user right after installation, that gets much trickier due to Apple placing restrictions on what can be done as the user from a root context. But its possible. Surprisingly, its more reliable under 10.10.x and 10.11.x than it was under 10.9 or earlier, although if you go back far enough in OS versions the same restrictions weren't really there so it was kind of a non issue.