Skip to main content

It seem that this is one of the biggest issues I deal with. LaunchAgents and LaunchDaemons that launch before the network service is up or so it appears. We have lots of these that depend on the network being up. In one particular case, we have a script executed via casper policy when a user logs in. This script mounts a few different network shares. The machines that are scoped in this policy are 30 mac minis that are part of a render farm. We have these 30 machines login automatically with a service account.



These machines boot with SSDs, so they are crazy fast. Probably adding to the issue. When the jamf launchagent runs, the JSS and the network resources cannot be reached because the network service is not yet up on the client. Is anyone else dealing with a similar thing? Could there be a way to way to delay the launchagent until the network is up? Maybe make this a toggable field? I'm sure I'd introduce new problems doing so. For now I'm left to create an offline policy that delays all other policies.



Here is what apple says about the issue:



Network Availability
If your daemon depends on the network being available, this cannot be handled with dependencies because network interfaces can come and go at any time in OS X. To solve this problem, you should use the network reachability functionality or the dynamic store functionality in the System Configuration framework. This is documented in System Configuration Programming Guidelines and System Configuration Framework Reference. For more information about network reachability, see “Determining Reachability and Getting Connected” in System Configuration Programming Guidelines.



thanks.
mark

Getting into the Sys Configuration Framework is probably worthwhile in the long run, but for the present could you simply add a 'sleep' to your mounter scripts with a generous number of seconds set while you wait for the network to come up?

Thanks for the response. Yeah, I can add sleep to my mount scripts but I'm concerned that the jamf launchagent would be the one that needs the sleep put into it because when it is the one that triggers login scripts (via policies), right? As of right now it tries to reach the JSS, but fails because the network isn't up. So none of the other scripts run. I could set those other scripts/policies to "Make Available Offline", but they don't get cached until it can actually reach the JSS, I believe. It usually requires me logging out and logging back in to trigger it. That seems to be my best option for now. I'm not familiar with the Sys Configuration Framework. Maybe I should look into it.

Part of my issue is that I can't trigger jamf to give the client a new offline policy script because it can't reach the JSS on automatic login. So my only option is to logout on the machines and login manually. It is then able to reach the JSS and get updates to offline policies/scripts. Or so it seems. Is there some way around this? Where you can send a jamf command to a machine that gets new offline policies/scripts for login or logout or whatever. Is there such a command?

Reply


Terms & ConditionsCookie settings