Shims panic on an unrecognised command-line flag #1180

containerd-shimkit panics when it cannot parse its command line, so a shim
binary given an unrecognised flag aborts with a backtrace notice rather than
saying what was wrong.

crates/containerd-shimkit/src/sandbox/cli.rs, in shim_main:

let flags = parse(&os_args[1..]).unwrap();

parse defines -v and -info; anything else is an Err, and .unwrap()
turns that into a panic.

Reproducing

Measured with a shim built on containerd-shimkit 0.1.2:

$ containerd-shim-example-v1 --version
thread 'main' panicked at .../containerd-shimkit-0.1.2/src/sandbox/cli.rs:229:38:
called `Result::unwrap()` on an `Err` value:
  InvalidArgument("flag provided but not defined: -version")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
101

--version is not special: -version and any other undefined flag do the same.
-v works and exits 0.

Why it seems worth fixing

Exit 101 with a backtrace notice reads as a crash in the shim rather than as a
usage error, and --version is a natural thing to try on a binary that was just
placed on a node. A shim is also a program containerd execs, so it is worth it
being well behaved about arguments it does not recognise.

The smallest fix is to print the error and exit non-zero instead of unwrapping.
Whether --version should also be accepted as a spelling of -v is a separate
question.

Related

#1119 asked for -info and is closed. It reports a panic in the same file, at
the logger initialisation rather than at argument parsing, so this is a
different failure with the same shape. That issue notes the class is cosmetic,
which is true here too — the shim works; it is only unhelpful when misused.

Found while smoke-testing a shim after installing it on a node, in a project
built on containerd-shim-wasm.