An option to Background scripts instead of waiting for them.

[wakco]

Is your feature request related to a problem? Please describe.
Currently outset will execute each script in an events folder, in turn, waiting for each script to complete before executing the next script. I'd like a way to change that behaviour on a per script basis.

Describe the solution you'd like
While I'm unsure of how it would go for a Managed Profile supplied script (probably just an option with the script), for installed scripts, have an array in the Config. Profile simply listing the full-paths to all the scripts to background (not wait for completion before starting the next script).

Describe alternatives you've considered
One of the reasons for outset's existence is to reduce the need to create launchd plists for each script, therefore reducing bloat in the Login Items lists, this would help with that, since currently that is the only way to allow scripts to in parallel.

Additional context
Some examples for this feature:

• I have a login dialog script, that opens over the login-window, this dialog gets updated based on things like network state changes, which requires the script to stay running in a loop, which effectively means any script that might run after it (I'm not doing this, at least not for the login-window context).
• I'm in the process of setting up an on login activation script, to which I've had to create a LaunchAgent plist for, because I do have other scripts in the login-every folder, and it or they get held up based on the order the scripts execute in, as such the wait time for the activation (of FortiClient ZTNA) often ended up as long if not longer than using a Jamf Policy configured for login (as it is, I've had to put into that script a wait to be sure it can activate, i.e. internet access, so anything else that might slow it down is a problem).

[bartreardon]

sounds like a good idea.

Just thinking aloud but another idea might be that tasks that are safe to background could be prepended with an _ e.g.

# run sequentially
# script2 runs after script1
my_script1.sh
my_script2.sh

# run in the background
# task1 and task2 run simultaniously
_my_background_task1.sh
_my_background_task2.sh

[wakco]

kewl, I chose the config. profile method as that at least seemed in-line with the checksum security feature.

Could do both, but require the config. profile method when the checksum security feature is in use. That would make script testing easier, while still having the extra security on deployment, and then just log a warning that a _script wasn't backgrounded because checksum security is enabled (when not listed in the config. profile).

[bartreardon]

I'll play around with the idea. could do one or both

[wakco]

As for the array in config profile idea, another idea that might be somewhat more future proofed, is to replace the sha256sum dict of script path strings containing checksums, with a security dict of script path dict's, each with keys for checksum/sha256sum, and backgrounding, and potentially much more. But I'm just spitballing.

[arubdesu]

I'm inclined to be concerned that (among other issues this could raise) logs will still be written to/via stdout effectively? This is essentially asking for multiprocessing which could potentially cause contention for resources? I mean sometimes you let problems be problems and the people opting in know that if/when it breaks they get to deal with any hints of inconsistency/issues

[bartreardon]

I'm certainly up to hear all sides for and against

In terms of logs, one could have a seperate log file for each script that runs which would avoid multiplexed log files. Everything should be sent to the system log as well so you should be able to filter there as well (although that seems to be less popular among admins who prefer old school log files)

There may be other ways to think about achieving the desired result. For example, have outset trigger a main script that spawns additional scripts and tasks and backgrounds them as required. This could be in the form of multiple other files you deploy to devices or as functions within the main script that perform your task that you background within the script, e.g.

#!/bin/zsh

task1() {
   # do task 1 stuff here
}

task2() {
   # do task 2 stuff here
}

task3() {
   # do task 3 stuff here
}

main() {
    task1 &
    task2 &
    task3 &
}

main

[mbrotz]

Hi!

I am very much in favor of adding a background execution feature to outset! I also like the _-idea!

We use outset a lot in our organization. We have some long running scripts at boot/login, which i am currently planning to move over to launchd because of this.

Alternatively, supporting an execution priority setting on a per script basis would allow me to define short running scripts to be executed first and the long running scripts to be executed last. The scripts would simply be sorted first by priority, then by name, and the scripts without explicitly set priority would be sorted AFTER all those with an explicitly set priority.