• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

ooni / probe-cli / 340
72%

Build:
DEFAULT BRANCH: master
Ran 13 Feb 2020 02:00PM UTC
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

13 Feb 2020 01:53PM UTC coverage: 3.545% (-0.001%) from 3.546%
340

push

travis-ci

web-flow
Optionally treat EOF on stdin just like SIGTERM (#111)

* 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 th... (continued)

7127 of 201054 relevant lines covered (3.54%)

0.04 hits per line

Jobs
ID Job ID Ran Files Coverage
1 340.1 13 Feb 2020 02:00PM UTC 0
3.54
Travis Job 340.1
Source Files on build 340
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #340
  • 040bee0e on github
  • Prev Build on master (#337)
  • Next Build on master (#345)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc