Unclear how this works as a brew service?

[Mahoney]

Hi,

I installed this via brew, and ran it as a brew service, and nothing happened.

Looking at it, I don't understand how it ever could - ASIMOV_ROOT is defined as ~, but run as a brew service it will be running as root, and for root ~ is /var/root, which is unlikely to be where you want to look for things to exclude?

Perhaps I'm missing something?

[aditya-arcot]

Looks like this is still the case. ASIMOV_ROOT expands to /var/root when the service is run.

The current behavior of running Asimov as a root service is required to allow it to run on startup (source). Homebrew services enforce this via require_root.

Homebrew also doesn't seem to allow specifying a non-root user for a system-level daemon (adding UserName property to the plist). Even if it did, this wouldn't be ideal since multiple installations on a single machine would cause issues.

There are 2 possible solutions I can think of:

Change to User-Level Launch Agent

The program would run as the logged-in user.

Pros

• ASIMOV_ROOT expands to the user's home directory.

Cons

• Service cannot run at system startup.
• Service only runs when user is logged in.
• System-level directories cannot be excluded.

Possible mitigation

• Increase the interval frequency to reduce the risk of missing updates.

Keep as System-Level Launch Daemon & Change ASIMOV_ROOT

The service would continue to run as root.
The program would use the filesystem root as default unless one or more locations are specified in a config file.

Pros

• Runs on system startup.
• Single installation serves all users.

Cons

• Longer runtime if scanning '/' by default.
• Config file adds complexity.

[pindab0ter]

To me a user-level launch agent seems fit for purpose.

• Not being able to run at system startup is mitigated by being able to run when the user is logged in, which is de facto the same thing.
• System-level directories to my knowledge do not contain dependency directories (please correct me if I'm wrong here)
• The Asimov service would no longer require elevated privileges, which is preferable

[aditya-arcot]

I agree. This seems like the best option moving forward.