starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 23:15:57 +03:00

[GH-ISSUE #1591] macOS Ventura boot loop (arm64 and amd64) #995

New issue

Closed

opened 2026-03-02 02:20:29 +03:00 by kerem · 5 comments

kerem commented

2026-03-02 02:20:29 +03:00

Owner

Originally created by @ghost on GitHub (Aug 9, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1591

macOS 13 (Ventura)

Agent version: 2.4.9

Installing either arm64 or amd64 agents on two macOS Ventura machines causes boot loop on both machines. Other Ventura machines have no problems.

It appears that the agent isn't the sole cause as the boot loop stops after being removed from the client list in TRMM even after rm 'ing the agent itself.

Both affected machines are Apple M1 / M2 processors.

Originally created by @ghost on GitHub (Aug 9, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1591 macOS 13 (Ventura) Agent version: 2.4.9 Installing either arm64 or amd64 agents on two macOS Ventura machines causes boot loop on both machines. Other Ventura machines have no problems. It *appears* that the agent isn't the sole cause as the boot loop stops after being removed from the client list in TRMM even after rm 'ing the agent itself. Both affected machines are Apple M1 / M2 processors.

kerem closed this issue

2026-03-02 02:20:29 +03:00

kerem commented

2026-03-02 02:20:30 +03:00

Author

Owner

@ghost commented on GitHub (Aug 9, 2023):

7 machines now. All Ventura apart from one on 11.7, either M or x64 processors.

The launchdeamon also needs to be deleted to fix it.

@ghost commented on GitHub (Aug 9, 2023): 7 machines now. All Ventura apart from one on 11.7, either M or x64 processors. The launchdeamon also needs to be deleted to fix it.

kerem commented

2026-03-02 02:20:30 +03:00

Author

Owner

@silversword411 commented on GitHub (Aug 11, 2023):

You're saying your Mac is constantly restarting when the TRMM agent is installed?

Can you provide something showing it's TRMM doing it like a log file or something? I've got 30+ Mac's, and don't have a problem with any of them

You sure you don't have a check script that has a reboot command built in or something?

@silversword411 commented on GitHub (Aug 11, 2023): You're saying your Mac is constantly restarting when the TRMM agent is installed? Can you provide something showing it's TRMM doing it like a log file or something? I've got 30+ Mac's, and don't have a problem with any of them You sure you don't have a check script that has a reboot command built in or something?

kerem commented

2026-03-02 02:20:30 +03:00

Author

Owner

@ghost commented on GitHub (Aug 11, 2023):

You sure you don't have a check script that has a reboot command built in or something?

Ah, good call. There is an uptime check script. I've disabled it and will monitor today.

@ghost commented on GitHub (Aug 11, 2023): > You sure you don't have a check script that has a reboot command built in or something? Ah, good call. There is an uptime check script. I've disabled it and will monitor today.

kerem commented

2026-03-02 02:20:30 +03:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2023):

The uptime script was the cause of the problem. I tried changing it but it made no difference to problem.

Can someone check this script and tell me why it works with other RMM software but not TRMM?

#!/bin/bash

# Get the system uptime
uptime_output=$(uptime)

# Extract the uptime value from the output
uptime=$(echo "$uptime_output" | awk '{print $3}')

# Remove the trailing comma from the uptime value
uptime=${uptime%,}

# Check if uptime is greater than 7 days
if (( $(bc <<< "$uptime > 7") )); then
  echo "System uptime is greater than 7 days. Rebooting..."
  (sleep 120; sudo reboot) &
  echo "Reboot scheduled"
  
else
  echo "System uptime is within 7 days. No reboot required."
fi

@ghost commented on GitHub (Aug 12, 2023): The uptime script was the cause of the problem. I tried changing it but it made no difference to problem. Can someone check this script and tell me why it works with other RMM software but not TRMM? ``` #!/bin/bash # Get the system uptime uptime_output=$(uptime) # Extract the uptime value from the output uptime=$(echo "$uptime_output" | awk '{print $3}') # Remove the trailing comma from the uptime value uptime=${uptime%,} # Check if uptime is greater than 7 days if (( $(bc <<< "$uptime > 7") )); then echo "System uptime is greater than 7 days. Rebooting..." (sleep 120; sudo reboot) & echo "Reboot scheduled" else echo "System uptime is within 7 days. No reboot required." fi ```

kerem commented

2026-03-02 02:20:30 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Aug 12, 2023):

I can't help with fixing your script but I can tell you what's wrong.

Relying on "relative" commands is not good. I have Homebrew installed and uptime is pulling from the Homebrew version, not the macOS version. This means you might get different results depending if Homebrew or other software is in the path. Compare the output of the two commands.

$ /opt/homebrew/opt/coreutils/libexec/gnubin/uptime
 09:06:55  up   0:32,  5 users,  load average: 1.22, 1.22, 1.42

$ /usr/bin/uptime
 9:07  up 33 mins, 5 users, load averages: 1.20 1.21 1.42

Comparing the output between the two, you should see the problem. Your awk '{print $3}' expression is taking the 3rd word as days. In the Homebrew version, the 3rd word is HH:MM minutes and in the macOS version, the 3rd word is NN minutes. This is why your script is boot looping. It's comparing the uptime in minutes if it hasn't been up for at least a day.

To fix that, you might want to look into the last reboot command. This will show the last time the computer was rebooted. Linux has the same command but in a different format.

$ /usr/bin/last -1 reboot
reboot    ~                         Sat Aug 12 08:34

To extract the date, we can go back to awk. In case you don't know, awk assigns the input to the $1 variable for the first word, $2 for the 2nd word, $3 for the third word, etc. $0 refers to the entire line. Assigning "" to $1 and $2 removes that "word" from the line. The sub() function removes the leading whitespace. The result is just the date.

$ /usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^  */,"", $0); print $0;}'
Sat Aug 12 08:34

Now let's convert that date to something meaningful. The date command can process dates and output a formatted date. Use man date for details. -j means "do not try to set the date". This is important because TRMM is running as root. -f contains the input format while "+..." represents the output format. See man strftime for details about the date formats.

/bin/date -j -f '%a %b %e %H:%M' "+%Y-%m-%d %H:%M:%S" "$(/usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^  */,"", $0); print $0;}')"
2023-08-12 08:34:19

This shows we can correctly process the date and control the output. According to strftime, %j represents "the day of the year as a decimal number (001-366)." You can use this to calculate the number of days between the last reboot and "now" as shown in the 2nd command. This logic will fail at the end of the year. I'll leave it up to you to determine how to fix that edge case.

/bin/date -j -f '%a %b %e %H:%M' "+%Y%j" "$(/usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^  */,"", $0); print $0;}')"
2023224
/bin/date -j "+%Y%j"
2023224

@NiceGuyIT commented on GitHub (Aug 12, 2023): I can't help with fixing your script but I can tell you what's wrong. Relying on "relative" commands is not good. I have Homebrew installed and `uptime` is pulling from the Homebrew version, not the macOS version. This means you might get different results depending if Homebrew or other software is in the path. Compare the output of the two commands. ```bash $ /opt/homebrew/opt/coreutils/libexec/gnubin/uptime 09:06:55 up 0:32, 5 users, load average: 1.22, 1.22, 1.42 ``` ```bash $ /usr/bin/uptime 9:07 up 33 mins, 5 users, load averages: 1.20 1.21 1.42 ``` Comparing the output between the two, you should see the problem. Your `awk '{print $3}'` expression is taking the 3rd word as days. In the Homebrew version, the 3rd word is `HH:MM` minutes and in the macOS version, the 3rd word is NN minutes. This is why your script is boot looping. It's comparing the uptime in minutes if it hasn't been up for at least a day. To fix that, you might want to look into the `last reboot` command. This will show the last time the computer was rebooted. Linux has the same command but in a different format. ```bash $ /usr/bin/last -1 reboot reboot ~ Sat Aug 12 08:34 ``` To extract the date, we can go back to awk. In case you don't know, `awk` assigns the input to the `$1` variable for the first word, `$2` for the 2nd word, `$3` for the third word, etc. `$0` refers to the entire line. Assigning `""` to `$1` and `$2` removes that "word" from the line. The `sub()` function removes the leading whitespace. The result is just the date. ```bash $ /usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^ */,"", $0); print $0;}' Sat Aug 12 08:34 ``` Now let's convert that date to something meaningful. The `date` command can process dates and output a formatted date. Use `man date` for details. `-j` means "do not try to set the date". This is important because TRMM is running as root. `-f` contains the input format while `"+..."` represents the output format. See `man strftime` for details about the date formats. ```bash /bin/date -j -f '%a %b %e %H:%M' "+%Y-%m-%d %H:%M:%S" "$(/usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^ */,"", $0); print $0;}')" 2023-08-12 08:34:19 ``` This shows we can correctly process the date and control the output. According to `strftime`, `%j` represents "the day of the year as a decimal number (001-366)." You can use this to calculate the number of days between the last reboot and "now" as shown in the 2nd command. This logic will fail at the end of the year. I'll leave it up to you to determine how to fix that edge case. ```bash /bin/date -j -f '%a %b %e %H:%M' "+%Y%j" "$(/usr/bin/last -1 reboot | awk '{$1=""; $2=""; sub(/^ */,"", $0); print $0;}')" 2023224 /bin/date -j "+%Y%j" 2023224 ```

kerem referenced this issue

2026-03-14 04:30:13 +03:00

[GH-ISSUE #995] Scripts run thru bulk script doesn't appear in audit log #2550