there was a race where ip-up could write ifname and then
ip6-up could write its outputs and then test ifname and
signal ready before ip-up had written the rest of its outputs
when the peer bounces ppp, s6 will restart the ppp process but not
restart the dependent services (because the service isn't considered
to have gone down)
so the dependent services need to notice when the outputs from ppp
have changed
because what happens if the service is restarted but the new ppp0 is
a different interface than the old one so that services which had
bound to it with the old name are now not getting new data
(I am not 100% that this actually happens but it seems like it would
be good to avoid it if it does)
it was only working by accident, when it worked, which was by no
means all of the time
note that we unconditionally perform the action (restart or whatever)
once we've started and got the initial state of the outputs. That's
because we have no idea whether the outputs changed in the interval
between the controlled service initially starting and watch-outputs
starting, so updates in that interval could be lost
we change the inotify watcher so that it attempts to monitor
/run/service as well as /run/service/foo. If foo doesn't yet exist
then that call to addwatch fails, so we need to be looking at the
parent if we are to be told when foo gets created
properties are similar to outputs, but are different in that they are
fixed values (do not change) and are present even when the service is
down
if the attribute is present and an attrset, this will write the
equivalent recursive directory structure to $out/.properties/
