Skip to main content
Jamf Nation, hosted by Jamf, is a dynamic and knowledgeable community of Apple-focused IT admins and Jamf Pro users. Join us in person, in October, for the annual Jamf Nation User Conference (JNUC) to discover new and better ways to manage Apple devices.
9

Mysterious script errors

Posted: 7/7/11 at 11:09 AM by Account deleted

Has anyone seen –10810 errors when executing scripts from either Casper Remote or JSS policies?

I'm trying to send an AppleScript to users informing them that they have updates available for their 3rd Party apps. They have the option of ignoring for the time being or clicking OK to run the updates (a 'do shell script' command that triggers a bunch of policies, based on whatever apps the user has installed)

Occasionally, the script runs fine and the user is prompted accordingly. But other times the user sees nothing, and I get:

Script Result: /private/tmp/JulyPrompt.scpt: execution error: An error of type -10810 has occurred. (-10810)

We're still running 7.31, but I'm not sure if that makes a difference.

9

Posted: 7/7/11 at 1:43 PM by sean

I have seen this error code before. If I remember correctly it was someone trying to write a script that needed to interface with the gui. Of course, if no one is logged in, then you can't do this. Hence the error message and why it works sometimes, but not others.

You can check who is logged in with:

stat -f%Su /dev/console

You can run this in Applescript with

do shell script ("stat -f%Su /dev/console")

If the machine is at the login window, then the reply will be root. So just do a test and if user isn't root, then run. Clearly assuming that no one logs into the gui as root on your machines. Hoping that this is a safe assumption.

Of course, I may have misremembered! If it isn't this, then you may need to post your script.

Sean

Posted: 7/8/11 at 2:16 AM by sean

install_test.scpt: execution error: An error of type -10810 has occurred. (-10810)

10810 is a gui issue as I initially thought. I achieved this error whilst the screen saver was on at the time the script ran. I also managed to receive the error whilst front row was running. There are clearly various reasons why the gui would not be available and if you feel the need, you are going to have to capture them all in your script.

----------------------------------------------------

install_test.scpt: execution error: System Events got an error: AppleEvent timed out. (-1712)

This is if no one pushes a button on the first window. You have no 'give up' equivalent on the first dialog box.

-----------------------------------------------------

There are various conditions that you will need to catch if you wish to do this.

Sean

--missing content--

2 were -10810 errors
2 were -1712 errors(AppleScript timed out)
1 was 901 error(custom error I threw if user was root)
1 was not a 901, but mentions not being able to open a WindowService
before login

The script compiles and runs locally with no issues, and also runs locally
on all of the machines having issues if I send it and run it manually.

I'm pretty much at a loss for explanation.

On 7/7/11 1:43 PM, "Sean Holden" <Sean.Holden at framestore.com> wrote:

I have seen this error code before. If I remember correctly it was someone trying to write a script that needed to interface with the gui. Of course, if no one is logged in, then you can't do this. Hence the error message and why it works sometimes, but not others. You can check who is logged in with: stat -f%Su /dev/console You can run this in Applescript with do shell script ("stat -f%Su /dev/console") If the machine is at the login window, then the reply will be root. So just do a test and if user isn't root, then run. Clearly assuming that no one logs into the gui as root on your machines. Hoping that this is a safe assumption. Of course, I may have misremembered! If it isn't this, then you may need to post your script. Sean ----- Original Message ----- From: "Bob Feldhake" <bob.feldhake.pyb3 at statefarm.com> To: "casper" <casper at list.jamfsoftware.com> Sent: Thursday, 7 July, 2011 5:09:09 PM Subject: [Casper] Mysterious script errors Has anyone seen =C2=AD10810 errors when executing scripts from either Casp

er

Remote or JSS policies? I'm trying to send an AppleScript to users informing them that they have updates available for their 3rd Party apps. They have the option of ignoring for the time being or clicking OK to run the updates (a 'do shell script' command that triggers a bunch of policies, based on whatever apps the user has installed) Occasionally, the script runs fine and the user is prompted accordingly. But other times the user sees nothing, and I get: Script Result: /private/tmp/JulyPrompt.scpt: execution error: An error of type -10810 has occurred. (-10810) We're still running 7.31, but I'm not sure if that makes a difference.
Casper mailing list Casper at list.jamfsoftware.com http://list.jamfsoftware.com/mailman/listinfo/casper

Posted: 7/8/11 at 9:00 AM by Account deleted

Thanks Sean,

Added the login check, but that doesn't appear to have fixed the problem.
On the 8 machines that ran the script yesterday, only 2 succeeded.

--missing content--

2 were -10810 errors
2 were -1712 errors(AppleScript timed out)
1 was 901 error(custom error I threw if user was root)
1 was not a 901, but mentions not being able to open a WindowService
before login

The script compiles and runs locally with no issues, and also runs locally
on all of the machines having issues if I send it and run it manually.

I'm pretty much at a loss for explanation.

Posted: 7/8/11 at 9:52 AM by sean

I think we'd need to see the script.

Sean

--missing content--

2 were -10810 errors
2 were -1712 errors(AppleScript timed out)
1 was 901 error(custom error I threw if user was root)
1 was not a 901, but mentions not being able to open a WindowService
before login

The script compiles and runs locally with no issues, and also runs locally
on all of the machines having issues if I send it and run it manually.

I'm pretty much at a loss for explanation.

On 7/7/11 1:43 PM, "Sean Holden" <Sean.Holden at framestore.com> wrote:

I have seen this error code before. If I remember correctly it was someone trying to write a script that needed to interface with the gui. Of course, if no one is logged in, then you can't do this. Hence the error message and why it works sometimes, but not others. You can check who is logged in with: stat -f%Su /dev/console You can run this in Applescript with do shell script ("stat -f%Su /dev/console") If the machine is at the login window, then the reply will be root. So just do a test and if user isn't root, then run. Clearly assuming that no one logs into the gui as root on your machines. Hoping that this is a safe assumption. Of course, I may have misremembered! If it isn't this, then you may need to post your script. Sean ----- Original Message ----- From: "Bob Feldhake" <bob.feldhake.pyb3 at statefarm.com> To: "casper" <casper at list.jamfsoftware.com> Sent: Thursday, 7 July, 2011 5:09:09 PM Subject: [Casper] Mysterious script errors Has anyone seen =C2=AD10810 errors when executing scripts from either Casp

er

Remote or JSS policies? I'm trying to send an AppleScript to users informing them that they have updates available for their 3rd Party apps. They have the option of ignoring for the time being or clicking OK to run the updates (a 'do shell script' command that triggers a bunch of policies, based on whatever apps the user has installed) Occasionally, the script runs fine and the user is prompted accordingly. But other times the user sees nothing, and I get: Script Result: /private/tmp/JulyPrompt.scpt: execution error: An error of type -10810 has occurred. (-10810) We're still running 7.31, but I'm not sure if that makes a difference.
Casper mailing list Casper at list.jamfsoftware.com http://list.jamfsoftware.com/mailman/listinfo/casper
CCA Badge

Posted: 7/8/11 at 9:55 AM by nessts

are you using http on your distribution point? try disabling http and use afp only.

--
Todd Ness
Technology Consultant/Non-Windows Services
Americas Regional Delivery Engineering
HP Enterprise Services

Posted: 7/8/11 at 1:09 PM by Account deleted

Script is attached. Feel free to take a look and offer any suggestions.

I'm open to accomplishing this task in a different way too, if anyone has
any suggestions. Just need to get these apps updated with minimal impact
to the user.

Thanks,
Bob

CCA Badge

Posted: 7/8/11 at 1:22 PM by nessts

yes but, it is easier to manage with PlistBuddy if you can get the syntax correct
you could read the array until you find the correct location…
pusedo code…
count = 0;
found = no
loop until found = yes
name = /usr/libexec/PlistBuddy "$home/Library/Preferences/com.apple.sidebarlists.plist" -c "Print systemitems:VolumesList:$count:Name"
if name != iDisk
count ++
else
found = yes
end if

write proper visibility to $count /usr/libexec/PlistBuddy "$home/Library/Preferences/com.apple.sidebarlists.plist" -c "Print systemitems:VolumesList:$countVisibility NeverVisible"

it is the more appley way of doing things and you have less chance of breaking the plist.

I consider this a golden nugget of learning I received today, and when I get one of those I usually call it a good day, have not had a good day in a long long time….

--
Todd Ness
Technology Consultant/Non-Windows Services
Americas Regional Delivery Engineering
HP Enterprise Services

--missing content--

2 were -10810 errors
2 were -1712 errors(AppleScript timed out)
1 was 901 error(custom error I threw if user was root)
1 was not a 901, but mentions not being able to open a WindowService
before login

The script compiles and runs locally with no issues, and also runs locally
on all of the machines having issues if I send it and run it manually.

I'm pretty much at a loss for explanation.

Posted: 7/8/11 at 5:47 PM by rockpapergoat

rather than modifying the plist all over the place, why not manage it via mcx?

i've done so before with no trouble. it's easier to manage.

Posted: 7/8/11 at 5:49 PM by rockpapergoat

munki basically does what you're looking for in a more maintainable way.

http://code.google.com/p/munki

i recommend testing munki to see if it suits your needs.