Superman 5.0.0 running update before user gets opportunity to log in

[david-london]

Hi

First - I really, really like this project - thank you.

I had two test users report that with Superman 5.0.0 their machines restarted shortly after they started up in the morning and installed the just released update with no chance of deferral. Both users reported that they logged on as soon as the machines came up but when I look in the super.log file I see this kind of entry

Tue Oct 29 08:22:42 dep69226 super[435]: Status: No GUI user currently logged in.

I got them to run "last" to try and figure out timing

itadmin    ttys000  10.131.249.177         Tue 29 Oct 09:42 - 14:19  (04:36)
itadmin    ttys000  10.131.249.177         Tue 29 Oct 09:10 - 09:19  (00:08)
00014170   console                         Tue 29 Oct 08:37   still logged in
00014170   console                         Tue 29 Oct 08:36 - 08:37  (00:00)
reboot time                                Tue 29 Oct 08:35
shutdown time                              Tue 29 Oct 08:32
root       console                         Tue 29 Oct 08:30 - shutdown  (00:01)
00014170   console                         Tue 29 Oct 08:23 - 08:30  (00:07)
reboot time                                Tue 29 Oct 08:22

So if I'm reading this correctly, the machine started at 8:22, super started doing stuff at 8:22:42 and then the user logged in at 8:23. Super is just too darn quick!

Is there a way to disable super from doing anything when nobody is logged in? With people being mobile so much they frequently shut down. There was apparently no pop up to allow deferral but I can see that was because this started when super decided nobody was logged in.

I'm just trying to avoid somebody getting an update like this and they are just launching into a presentation. The big feature for me is the ability to defer for a set number of days but it seems like there is a small window where super can just bypass everything. I appreciate that in some cases you want super to install when nobody is logged in - I have labs where that's my plan but in the scenario above even if it waited for a set time to make sure someone wasn't just booting, it would be helpful

2024-10-29_dep69226_super.log
dep69226_last.txt

[Macjutsu]

Indeed... super started up and saw that no one was logged in... and then procededed to install.

This would need to be a new feature to NOT do that since a lot of folks (in shared lab situtations) expcect super to automatically install if there is no current user.

[david-london]

Thanks Kevin,

Yes, I want to take advantage of this "No GUI user currently logged in" for our labs. But for other people, it seems like super is too fast.

This is your baby but here's some suggestions:

• Instead of a LaunchDaemon, have Super run as a LaunchAgent if some configuration setting is made to only run super when a user is logged on.
• Have some sort of delay after restart variable that can be set to give the user at least a chance of logging in

I know you have a way bigger idea of how things work so as I said, just suggestions.

[Macjutsu]

No plans to move to an agent b/c that could cause a cascade of issues. That being said, I do plan to implement features that allows for control of super's workflow in reguards to user vs no user.

[rjashton]

We have seen this in our environment too. I understand that super sees that the user is not logged in and that starting the update flow is the correct logic but... I also think that the flow restarting a device with no warning to a user should not happen.

The improvements to the user experience and notification from super are one of the key things about it to me!

[sch4llfl3g3l]

We experienced the same in our environment.

As a workaround i have now modified the super-starter script to add a customizable delay after boot and just exit 0 when we are not past this delay. I guess 900 seconds (the value i chose) should be sufficient for everyone to sign in.

Of course i actually modified the super script (which writes the super-starter script).

This is a quick solution and may be implemented more elegant (e.g. call it by parameter).

Here is a diff output (includes some timeouts i modified too):

14a15,18
> # Delay super after system boot (in seconds) to prevent accidental update installation (with no warning at all)
> BOOT_DELAY=900
> readonly BOOT_DELAY
>
471c475
< TIMEOUT_INSTALLER_DOWNLOAD_SECONDS=300
---
> TIMEOUT_INSTALLER_DOWNLOAD_SECONDS=600
475c479
< TIMEOUT_INSTALLER_WORKFLOW_SECONDS=600
---
> TIMEOUT_INSTALLER_WORKFLOW_SECONDS=1800
479c483
< TIMEOUT_MDM_COMMAND_SECONDS=300
---
> TIMEOUT_MDM_COMMAND_SECONDS=900
483c487
< TIMEOUT_MDM_WORKFLOW_SECONDS=600
---
> TIMEOUT_MDM_WORKFLOW_SECONDS=900
3563a3568,3574
>
> # Exit this script if last boot time was under \${BOOT_DELAY} seconds
> kernel_boot_epoch=\$(sysctl -n kern.boottime | awk -F 'sec = |, usec' '{print \$2}')
> current_time=\$(date +%s)
> if [[ \$((current_time - kernel_boot_epoch)) -lt ${BOOT_DELAY} ]]; then
> exit 0
> fi
10834c10845
< exit_clean
---
> exit_clean

[david-london]

Hey @sch4llfl3g3l that looks like a better idea than what I was thinking of. Looks like you put the block:

# Exit this script if last boot time was under \${BOOT_DELAY} seconds
kernel_boot_epoch=\$(sysctl -n kern.boottime | awk -F 'sec = |, usec' '{print \$2}')
current_time=\$(date +%s)
if [[ \$((current_time - kernel_boot_epoch)) -lt ${BOOT_DELAY} ]]; then
	exit 0
fi

about line 3565 at the start of the super-starter script inside the super script - yes?

Also the block:

# Delay super after system boot (in seconds) to prevent accidental update installation (with no warning at all)
BOOT_DELAY=900
readonly BOOT_DELAY

is around line 14 in super

I'll give this a go and see if I get any issues

[sch4llfl3g3l]

Hi @david-london

line 3565 is correct (that makes it the first condition to be checked).
And BOOT_DELAY about line 14/15.
If this would be integrated into a release it wasn't the right place, but so far it is convenient for me (separate from the original code and i can quickly change it there).

Take care of the escaping backslashes when copying the code.

You can add a line with an echo message to a file in /tmp above the "exit 0", for debugging purposes.
That way you can check if the condition is properly executed after boot.
If so it must write 15 lines into that file if the BOOT_DELAY is 900 seconds (15 minutes - the launch daemon runs every minute)

[david-london]

Hi @sch4llfl3g3l

It looks to be working for me. The 15 minutes delay from startup seems like a reasonable time too.

I actually think this is a good compromise with how Kevin designed it. However, knowing the tight windows people have with labs sometimes, I think a way of turning this on via a config profile or startup settings would be needed for wider use.