* Optionally treat EOF on stdin just like SIGTERM
On Unix, Node.js allows us to gracefully kill a process. On Windows
this is more compex. You certainly cannot rely on the default `kill()`
function, which calls `TerminateProcess`.
There is a bunch of C/C++ extensions that in principle allow you to
attempt to gracefully shutdown a Windows process.
But, hey, here's a reality check. Node.js controls our stdin. Node.js
does IPC easy. Controlling uv_spawn flags and using the right not well maintained
C/C++ Node.js extension to kill a process is fragile.
So, treat EOF and any other error on stdin as equivalent to SIGTERM.
However, systemd.
The sane thing to do with systemd is `StandardInput=null`. With such
configuration, stdin immediately returns EOF.
Then, introduce the `OONI_STDIN_EOF_IMPLIES_SIGTERM` environment
variable. When it is `true`, this behaviour is enabled, e.g.:
```bash
export OONI_STDIN_EOF_IMPLIES_SIGTERM=true # behaviour enabled
ooniprobe run
```
I want the default to be disabled because:
1. in the future we may find a better way to solve this problem and I
don't want the _default behaviour_ to change in such case
2. we know we need this knob for ooniprobe-desktop, and we will not
fail to provide it, so it won't suprise/damage us
3. a person trying to write a systemd unit for ooniprobe would be very
surprised to find out they need to disable this behaviour, if it was
enabled by default by this PR
Hence, I believe this design is consistent with designing for the
future and for trying to minimize surprises.
Also, why an environment variable and not a command line flag? Because:
1. we don't want such hypothetical flag to be available where it does not
make sense, e.g., for all subcommands but `run`
2. we don't want the ooni/probe-desktop app to write conditional
code because it needs to check the command we're using and then decide
whether to add such hypothetical flag
Also, why not enabling this only on Windows? Because again we don't
want the ooni/probe-desktop app to write conditional code.
To summarize: we want ooni/probe-desktop app to see the same behaviour
everywhere and we want others to be the least surprised.
Related to https://github.com/ooni/probe/issues/1005
* Update ooni.go
Closes https://github.com/ooni/probe-engine/issues/316
Rationale: a measurement may fail for a bunch of reasons including
buts in the code. The original determination was that we won't
return an error from the measurement in case of anomaly. But doing
that is error prone, and indeed the Psiphon experiment was not
following this pattern. I claim that this pattern was wrong, and
it's much more in our interest to submit and store on disk anything
that we get from a measurement. This data can be useful to look
into bugs, as well as to discover novel anomalies we didnt' anticipate.
We were writing to the same measurement_file_path for a given test
group, because we were using a different filename only in the case of a
many input test, but not in the case of many test_names inside of a
given test group.
At this stage is fine to just pin to the latest master. I am planning on
blessing periodic releases and it's fine to pin sometimes.
I'm pinning this specific version because it currently supports the
summary for experiment/tor, which @sarathms would benefit from.
You should place the file inside of: `$HOME/Library/LaunchAgents` and then enable by running `launchctl load org.ooni.probe.cli.plist`
It assumes you have a `ooniprobe` binary in `~/.ooniprobe/ooniprobe` and a special config file named `/Users/USERNAME/.ooniprobe/config-100sites.json` with a URL limit of 100 sites per run:
```
"nettests": {
"websites_url_limit": 100
},
```
* go.mod go.sum: update all non-probe-engine deps
For each line in the go.mod, run `go get -u -v $package` if the
line is not an indirect dependency and is not probe-engine.
Upgrading probe-engine is going to require the same spell that
is used in probe-engine to update psiphon.
* go get -v github.com/ooni/probe-engine@v0.5.0
This just pins to the latest probe-engine but we've not manually
pinned all the other dependencieds yet.
Take care of the trivial API changes in probe-engine as well, such
that we can have a working build after this commit.
* go.mod go.sum: pin to probe-engine dependencies
Basically: remove all indirect dependencies. Merge this go.mod with
the one of probe-engine, to pin dependencies. Run `go mod tidy`.
* circumvention: add basic implementation of tor
This needs to be polished further, of course. But at least we have
now added support for running tor in the circumvention group.
* Readme.md: document how to update dependencies
* go get -v github.com/ooni/probe-engine@fcc9ee0a7afb
* go get -v github.com/ooni/probe-engine@4d254f5b2
* nettests/tor.go: implement summary test keys
* Use ~/.ooniprobe as the home directory
Remove all probe-legacy related to code since there is no more conflict
between the two
Fixes: ooni/probe#972
* Update .gitignore
Co-authored-by: Simone Basso <bassosimone@gmail.com>
1. only print time left if ETA is positive
2. skip ETA calculation with a single input
3. don't compute ETA for first entry[*]
[*] this is actually what avoids emitting infinite but the other
parts of this diff felt useful yak shaving as well.
Closes#91