Question for mm2270 regarding reboot scheduler script

[jriv]

Hi @mm2270 ,

First of all, thank you for this awesome script! We've been struggling with how to enforce critical OS updates (requires reboot) without being too invasive and your reboot scheduler script was just what we were looking for! I presented it to my boss and he was very impressed.

His suggestion to me was to "brand" it to make sure our users know that this is something from our IT Department and not anything nefarious. It's easy enough to edit the text but how can I change the dialog box icons? I noticed at least 3 system images used: Restart.tiff, Info and Caution. I see where you're referencing Restart.tiff icon="/System/Library/CoreServices/loginwindow.app/Contents/Resources/Restart.tiff" so I changed the path to point to our logo but there was no change. I wouldn't even know how to begin to change the references for the other two icons.

Any help would be very much appreciated!

Thank you again!

[jjones]

@jriv Could you link the thread that has that script? I'm interested in looking into it for use.

[mm2270 · Accepted solution]

Hi @jriv I'm glad you're finding the script useful.
As for changing the icons used, a few things may need to happen.

First, in any portion of the script where a cocoaDialog dialog box is being generated, if you want to use a custom logo for the icon, you may have to change the --icon flag to --icon-file instead. The former is used when it calls cocoaDialog's internal mechanisms to use a system level icon that should exist. For example, in the following command, I'm using the built in "Info" icon from the system

/path/to/cocoaDialog.app/Contents/MacOS/cocoaDialog msgbox --title "This is the title" --text "This is the text" --button1 OK --icon info

If I wanted to use a custom path to an icon, I can use the same basic syntax as above, but use the --icon-file flag instead and then add the path to the file, like so:

/path/to/cocoaDialog.app/Contents/MacOS/cocoaDialog msgbox --title "This is the title" --text "This is the text" --button1 OK --icon-file /path/to/icon.png

As for why the logo didn't change when you made the change in reference to your custom icon, I would be sure you changed the correct dialog in the script. There are several places in the script where cocoaDialog windows are called, so I'm not sure which one you wanted to change. You might have to scan the script to see which one it was you intended to change to be sure the change is happening in the right place. And of course, the icon file must exist on the Mac locally to be able to use it in the window. I assume you've deployed your company logo into a location somewhere where you can call it from? Also, what format is it in? I would use one of either PNG, JPG, TIF or ICNS. Any of those formats should work OK.

[jriv]

@mm2270 ,

Thanks for this! I got it working. I forgot that I moved the file and did not update the file path in the script to the new location. Follow up question regarding the launchdaemon: As I understand, if the mac is powered off when the scheduled reboot is supposed to occur, the launchdaemon will just sit there. In my testing, when the script runs again, it recognizes that there is already an existing launchdaemon and it fails to schedule a new reboot. Is there a way to work around this?

Thanks!

@jjones,

I don't remember the thread but here's mm2270 github: https://github.com/mm2270. Lots of goodies in here to browse through.

[mm2270]

@jriv Maybe I'm misunderstanding what you mean above, but, if you power the Mac off, when it comes back up, the reboot will no longer take place since in effect the Mac was "rebooted" Power off/power on is in effect the same as doing a reboot for all intents and purposes.
Basically, what happens is, the script runs at next check to see if the last boot time is different than what was originally recorded by the script when the reboot was scheduled. So for example, when the software is installed and the reboot scheduler script runs, it looks at the last boot timestamp of the Mac and records that information down. When the scheduled reboot arrives, or when the LaunchDaemon is next called, it checks to see if the current boot timestamp is after or later than the time of when the script first ran. If so, the user, or someone, manually restarted or shut down the Mac in the intervening time. Thus, the reboot is no longer necessary, at least as long as any additional installs weren't done.

Does that make sense, and does it answer your question?
If I'm mistaking what you meant, can you clarify it?

[jriv]

@mm2270

Might not be explaining myself correctly so I ran another test and grabbed logs.

When I ran the script, as expected it created the launchdaemon and was set the mac to reboot at 3:01PM.

A user "loaner" is logged in on this Mac. Proceeding...
No pre-assigned deferral was set for the script. Prompting user for input...
User chose a 30 minute deferral for reboot
Values needed for the LaunchDaemon have been determined
Values to be used for the LaunchDaemon's StartCalendarInterval:
Day:    28
Hour:   15
Minute: 1
Month:  10
This Mac will be set to reboot on 10/28 at 15:01:00
Creating the LaunchDaemon...
LaunchDaemon and script were successfully created. Correcting permissions on LaunchDaemon...
Making the script executable...
LaunchDaemon loaded successfully

After this, I shutdown the mac and did not power on until after 3:01PM. I agree that this is considered a reboot. I ran the script again and this time, received this output:

Executing Policy Reboot Scheduler
Running script reboot_scheduler...
Script exit code: 0
Script result: Start timestamp: Fri Oct 28 15:34:33 PDT 2016
A user "loaner" is logged in on this Mac. Proceeding...
This Mac has already been set up to reboot at a future date. We will not create an additional schedule.

When I look in /Library/LaunchDaemons/, com.org.rd.plist still exists even though it is set for 3:01PM on Oct. 28, 2016 (which is now in the past).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.org.rd</string>
    <key>Program</key>
    <string>/private/var/rtimer.sh</string>
    <key>RunAtLoad</key>
    <false/>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Day</key>
        <integer>28</integer>
        <key>Hour</key>
        <integer>15</integer>
        <key>Minute</key>
        <integer>1</integer>
        <key>Month</key>
        <integer>10</integer>
    </dict>
</dict>
</plist>

It looks like, the script is not overwriting the old launchdaemon even though it's an "old" one. It effectively makes it impossible to use the script again until the existing one is removed.

Is this normal behavior or do you think I accidentally change something in the script while I was editing the dialogs?

[mm2270]

Hi @jriv Ok, I get what you're saying now. I'm not sure if I designed the script to account for that kind of scenario, so I may need to go back and make revisions to it. Basically, once the StartCalendarInterval date has passed, the LaunchDaemon doesn't fire, which means the script doesn't get called and subsequently, the previous script and LaunchDaemon don't get cleaned up. I hadn't really thought of that aspect, so thanks for pointing that out.
I'll have to see what I can do to work around that and post back.

[jriv]

@mm2270 If you ever get around to adding to the script, please tag me if you can remember.

Thanks again!

[mm2270]

@jriv Sure thing. I plan on looking at that within the next week, but I can't make any guarantees at this point on how soon I will incorporate any changes. Just depends on when I can make the time to look at it.

[DJC]

Hi @mm2270

We've been using this script for a while and really like it but ran into this exact scenario. I found this rather old thread attempting to see if anyone else was experiencing the issue. We have reboots scheduled in the past for whatever reason that didn't go and all subsequent reboot attempts fail with the message that a future reboot is scheduled. I'm guessing that you never found the time to update the script but wanted to ask if simply running the Cleanup() tasks (deleting the plist, rtimer.sh, and unloading the launchdaemon) would be sufficient to allow the script to run again. While fixing the reboot script itself is beyond my scripting knowledge, I figure we can target machines with this error and run a separate script to effectively remove the old scheduled reboot.

Thanks.