It has been a while since I played around much with launchd, but I ran across a problem recently that it seemed perfectly suited to solve.
The challenge was as follows: there is a particular application that I need to run as root. When that application persists files, those files get written with root as the owner—but only if that app is the one creating the file. Then there is another command-line utility that I use to work with these files, but that utility expects those files to be owned by me (i.e.,
rob). This was causing a whole host of problems, mainly that files were not getting properly updated or removed when the utility was run on them.
To solve this manually (i.e., “the tedious way”) was easy; every time I ran into trouble with that command-line utility, I would type:
But who wants to do that every time?
The solution that I really wanted was for launchd to watch that directory and fix the permissions every time something was added.
chown is still the right tool for the job; but launchd takes the tedium out of it:
And ba-bam. Problem solved.
UPDATE: Did I speak too soon? During some initial testing, this appeared to work just fine. But after a full day of use… ran into some problems. As in, it’s not actually updating the ownership on these files. Raising the following questions:
- Was I seeing false positives before? and if so, how could that have happened?
- If this was actually working during the initial test, then why did it stop?
I’ve seen some weird stuff “out there” about the
WatchPaths directive—ranging from “the path must exist at all times” to “it does not actually watch the path you think it does”—but nothing conclusive. Thus: the quest continues.
- And of course, if you’re using this for something similar, you’ll want
rob:adminto be whatever
user:grouppair that you actually need. [↩]
- Though the exact namespace and filename is really up to you. I’m just typing that out as the example. [↩]
- …and/or via Lingon. [↩]