Policy to logout after a certain time idle

Contributor III

I created a script to restart a computer after 6 hours idle (by cobbling together stuff I'd found online):

exec 2>&1

# Get MacOSX idletime. Shamelessly stolen from http://bit.ly/yVhc5H
idleTime=$(/usr/sbin/ioreg -c IOHIDSystem | /usr/bin/awk '/HIDIdleTime/ {print int($NF/1000000000); exit}')

echo Idle Time is $idleTime seconds

if (( idleTime > 21600 )); then
sudo shutdown -r now
else exit 0

exit 0

That works, but it doesn't seem to trigger logout hooks. We use Jamf to manage lab computers and if we logout the lab account it will automatically restart the computer, so logging out the lab account would technically accomplish the same thing as restarting. If I type the following command into terminal, it immediately brings up a popup window saying it will logout in 60 seconds and then logs out:

osascript -e 'tell app "System Events" to log out'

But if I put that into my script (replacing "sudo shutdown -r now"), I get the error message "28:35: execution error: An error of type -10810 has occurred. (-10810)<br/>"

Any ideas? I know there is a Configuration Profile to logout users after certain amount of time, but it hasn't worked consistently for me so I'm trying to make an alternative.


Legendary Contributor III

Have you tried using a Configuration Profile with the "Log out users after: <X> Minutes of inactivity" which is in the Login Window payload? It seems this would achieve what you're after better than a script. Unless you're actually looking to have them restart and not just logout?

Contributor III

Thanks for your response. Yeah, as per my first post I know there's a Configuration Profile but it doesn't seem to consistently work for me. I feel like I'm close to doing it with what I have, but something's not working.

Legendary Contributor III

OK, sorry. I missed that you said you tried a Config Profile already. I'm not sure why it wasn't working, but I think I recall now that there are some issues with that option now in the OS, like it only works under certain circumstances, which makes it not very effective.

Here's something you can try. The reason the Applescript call is failing is because it's being run as root, not as the user, and macOS tends to block Applescript commands from running something as the user, unless you direct it to execute as the user.

## Get the logged in username
loggedInUser=$(stat -f%Su /dev/console)

## Get the logged in user's UID
loggedInUID=$(id -u "$loggedInUser")

## Run an Applescript logout immediately command as the user
/bin/launchctl asuser "$loggedInUID" sudo -iu "$loggedInUser" "/usr/bin/osascript -e 'ignoring application responses' -e 'tell application "loginwindow" to «event aevtrlgo»' -e end"

This should start a logout and ignore any open applications that might stop the logout. If that works, contain that entire section within your if/then block, if the idle time reaches the amount you specify.

Contributor III

Thanks! You were 100% right in that the issue seemed to be running it as root. I just changed the command to:

sudo -u $3 osascript -e 'tell app "System Events" to log out'

It worked great, and logout hooks ran! (also, for some reason when I had the "sudo shutdown" command it took about an hour for the script to start running again after the computer restarted, but with this command it ran normally every 15 minutes [check-in time]) I initially didn't want to force the logout, but after thinking about it I decided to go with it.

sudo -u $3 osascript -e 'tell application "loginwindow" to  «event aevtrlgo»'

Thanks again for your help!

Contributor III

Correction: That worked for 1 computer on our Dev environment. Pushed it to Production, have gotten the following on 3 computers if I look in the logs:

Script result: Idle Time is 22844 seconds
sudo: unknown user: osascript
sudo: unable to initialize policy plugin

Hmmm....Dev (9.98) and Prod (9.97) are different versions of JSS, may need to update Prod?

Legendary Contributor III

Yes, because $3 is not resolving to the username. It only works in a few instances when pushed from Jamf Pro. Login, Logout and some Self Service policies. If the policy is being called with the recurring trigger, it doesn't know what $3 means, so since that's blank, it thinks your script is trying to do sudo osascript -e...

Instead, get the logged in username, don't try to rely on $3, at least in this case. Use the code I show above to populate a loggedInUser variable and use that in place of $3

Contributor III

New entry works in Dev:

loggedInUser=$(stat -f%Su /dev/console)

sudo -u $loggedInUser osascript -e 'tell application "loginwindow" to  «event aevtrlgo»'

Will test out in Prod next week.

Thanks again for your help!

New Contributor III

I'd like to do something very similar. Have you gotten a script that will work? If so, do you mind posting your entire, now working, script and also the details of how you are triggering that script?



Provided you don't have another config profile targeting com.apple.loginwindow or com.apple.screensaver, it should work fine if you make a custom payload with the com.apple.securitypref.logoutvalue and com.apple.autologout.AutoLogOutDelay keys, or a script that sets them:

defaults write /Library/Preferences/.GlobalPreferences.plist com.apple.securitypref.logoutvalue -int $timeInSeconds
defaults write /Library/Preferences/.GlobalPreferences.plist com.apple.autologout.AutoLogOutDelay -int $timeInSeconds

Contributor III

I haven't managed to get this working yet (other issues have come up that made this sort of slide to the back of the line). I think I left it running on Production over the weekend (figuring that it would just run and keep giving that error), then when I came back Monday all the computers had restarted but they didn't automatically log into the Lab account (which they should normally do after restarting).

I keep running into issues where something will work in Development but not in Production, and there are so many variables (Development is 9.97, Production is 9.98, different computers are running OS 10.12.3-10.12.6) that my main concern right now is trying to get everything running in a standard configuration. Every time I find a way to block OS updates it works only until the next OS update comes out.

If I ever do get this worked out I'll definitely post it.