On 09/01/2015 19:52, Patrick Mahoney wrote:
> Hi,
>
> This is a small hack I'm experimenting with to allow an unmodified
> service to notify s6 when it is "really up". It does this by grepping
> the service's output for a certain pattern, then writing the U event.
>
> Is this a reasonable approach, or too hackish and silly?
It is definitely hackish, but it can work if the service's output is
guaranteed. The main problem is that the output doesn't directly flow
from the service to the logger, there's the tee process in the middle,
and it's not supervised - so if anything happens to it, your logs are
screwed, and the supervision tree isn't aware of anything being wrong.
> I feel like there could be a better implementation, one that doesn't
> leave a "cat >/dev/null" process hanging around forever.
Well the problem is that you want the service's output read by two
process, so you have to keep a tee even after you don't need the
duplication anymore.
There aren't many ways to avoid that. You could tell s6-log to update
a status file when it gets the "ready" line, and if you're on an OS
with a file change notification mechanism (Linux and OpenBSD, at least,
qualify), you can have a process spawned in the run script that waits
for the status file change, performs the s6-ftrig-notify, then dies.
Apart from that, I'm out of ideas to avoid extra long-lived processes
if you're doing things that way.
> pipeline -r { $_at_ }
That's an additional problem with this implementation: your daemon
now runs as a child of pipeline, so it's not directly supervised.
Use pipeline -w and run your shenanigans in the child process, so
the daemon always run as s6-supervise's direct child.
I'm convinced that the least hackish way would be to use
s6-log's "update status file" function and something like busybox inotifyd.
--
Laurent
Received on Fri Jan 09 2015 - 19:56:14 UTC