> > One way or the other, ./finish should only be used scarcely, for clean-up > duties that absolutely need to happen when the long-lived process has died: > removing stale or temporary files, for instance. Those should be brief > operations and absolutely cannot block. >
I'm thinking "spawn to background and exit just after that". > So, if you're implementing reporting in ./finish, make sure you are using > fast, non-blocking commands that just fail (possibly logging an error > message) if they have trouble doing their job. > > The way I would implement reporting wouldn't be based on ./finish, but on > an external set of processes listening to down/up/ready notifications in > /service/foobar/event. It would only work with s6, though. Unfortunately I don't have a firm plan for supporting framework enhancements just yet. Although every little note and suggestion you give will certainly be remembered, and when the time comes, I'll see what I can do to incorporate them. Right now I'm having an internal dialog about if I should have an environment variable that "hints" the framework to the scripts, which in turn would allow me to support framework-specific features. I like the idea but I'm concerned that it will be unmaintainable without templates. > > > -- > Laurent > >
