Closed agross closed 7 years ago
Presuming you don't use /usr/local/var
for alternative things yourself, it seems possible at some point in the past you installed something via Homebrew that had a plist
that needed to be root-owned to launch, and /usr/local/var/log
was created by that process. Also potentially something that didn't need to be root but had been configured to log in that directory and was initially executed with sudo xyz
.
We saw quite a bit of that at Homebrew before the process was changed to automagically create plist-named directories in postinstall
rather than letting a daemon create them.
Perhaps the simplest way is to add a "health" check to the command here that moans if you can't write to that directory or something similar.
Hm, so my macOS install is broken? I don't remember installing anything special but it might be the case with root as some brew installs required sudo (dupes IIRC). I went and changed the log directory to $HOME/Library/Logs
. I feel this is a better place since the plist is run when I log in. What do you think?
I wouldn't put it that strongly. It's more of a user/daemon configuration issue than it is a fundamental system issue. macOS doesn't use /usr/local/var
natively at all, so you could and very well may wish to chown
it back to your user, otherwise you might encounter similar issues with Homebrew formulae that create logs.
I did actually think about where the logs should live. On the one hand, Homebrew formulae log in HOMEBREW_PREFIX/var/log
or HOMEBREW_PREFIX/var/logs
generally. Homebrew itself generates build logs in ~/Library/Logs/Homebrew/
. So there's an argument for both, annoyingly 😄.
:+1:
The plist file specified that log files should be written to
/usr/local/var/log/homebrew.mxcl.autoupdate.{out,err}
. On my macOS Sierra these files are not writable by my user, hence the job always fails and LaunchControl shows error 87.