ooni / probe-cli / 329
4%
master: 72%

LAST BUILD BRANCH: refactor/no-forks
DEFAULT BRANCH: master
Ran
Jobs 1
Files 1201
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 3.504%. Remained the same
329

push

travis-ci

bassosimone 
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 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 do... (continued)

7045 of 201051 relevant lines covered (3.5%)

0.04 hits per line

Jobs
ID Job ID Ran Files Coverage
1 329.1 0
3.5
 Travis Job 329.1
Source Files on build 329
Detailed source file information is not available for this build.