Split out of #15457, let's see if this is the culprit of the CI failure.
(also setting green label here, since @keszybz already greenlit it in that other PR)
The submit phase of the Fuzzit Travis job has been spuriously failing
for some time with various (and usually pretty hidden) errors, like:
```
./fuzzit create job --type regression ...
2020/04/23 17:02:12 please set env variable FUZZIT_API_KEY or pass --api-key. API Key for you account: ...
```
```
./fuzzit create job --type regression ...
2020/04/23 11:36:53 Creating job...
2020/04/23 11:36:54 Uploading fuzzer...
2020/04/23 11:36:54 Job created successfully
2020/04/23 11:36:54 Get https://...&action=create: read tcp x.x.x.x:39674->x.x.x.x:443: read: connection reset by peer
```
```
./fuzzit create job --type regression ...
2020/04/22 18:09:15 Creating job...
2020/04/22 18:09:16 Uploading fuzzer...
2020/04/22 18:09:37 Job created successfully
2020/04/22 18:09:37 500 Internal Server Error
```
etc.
Let's retry each submit job up to three times to (hopefully) mitigate this.
It turns out that our man page didn't describe the handling of single-label
names almost at all. This probably adds to the confusion regarding the subject.
So let's first describe what our current implementation is doing.
Quoting https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/:
> Applications and platforms that apply a suffix search list to a single-label
> name are in conformance with IETF standards track RFCs. Furthermore,
> applications and platforms that do not query DNS for a TLD are in conformance
> with IETF standards track recommendations
Current behaviour is in line with that recommendation.
For #13763.
We unregister binfmt_misc twice during shutdown with this change:
1. A previous commit added support for doing that in the final shutdown
phase, i.e. when we do the aggressive umount loop. This is the robust
thing to do, in case the earlier ("clean") shutdown phase didn't work
for some reason.
2. This commit adds support for doing that when systemd-binfmt.service
is stopped. This is a good idea so that people can order mounts
before the service if they want to register binaries from such
mounts, as in that case we'll undo the registration on shutdown
again, before unmounting those mounts.
And all that, just because of that weird "F" flag the kernel introduced
that can pin files...
Fixes: #14981
Let's just copy out the bit of the string we need, and let's make sure
we refuse rules called "status" and "register", since those are special
files in binfmt_misc's file system.
Apparently if the new "F" flag is used they might pin files, which
blocks us from unmounting things. Let's hence clear this up explicitly.
Before entering our umount loop.
Fixes: #14981
let's return ENOSYS in that case, to make things a bit less confusng.
Previously we'd just propagate ENOENT, which people might mistake as
applying to the object being modified rather than /proc/ just not being
there.
Let's return ENOSYS instead, i.e. an error clearly indicating that some
kernel API is not available. This hopefully should put people on a
better track.
Note that we only do the procfs check in the error path, which hopefully
means it's the less likely path.
We probably can add similar bits to more suitable codepaths dealing with
/proc/self/fd, but for now, let's pick to the ones noticed in #14745.
Fixes: #14745
Norbert Lange