Priority: Major - P3
Resolution: Works as Designed
Affects Version/s: None
Fix Version/s: None
Backport Requested:v3.4, v3.2
I did run into a problem with mongodump when invoked from a third party backup tool called shield -> https://github.com/starkandwayne/shield
This tool uses a very plugin based approach, there is a plugin which does mongodb backups using mongodump and will then PIPE it into the plugin which takes care of storing the backup.
Whenever there is a problem, the tools sends a SIGPIPE which imho is the correct way to imply that sh*t hit the fan and that mongodump should abort, since something is wrong.
Now there is
TOOLS-1366 which explicitly disabled SIGPIPE in in signals.go -> https://github.com/mongodb/mongo-tools/blob/57233a4ef048b7f26bd5e4a6f8393160491c4306/common/signals/signals.go#L31 .
Basically what happens now is that the store plugins of shield happily sends a SIGPIPE but the process never exits because mongodump simply ignores this.
To be fair, I don't really agree with the point the author made in
TOOLS-1366. It might make sense for some tools which use common/signals/signals.go but when it comes to mongodump and probably also mongorestore, then I think this is a very bad idea.
Whenever something is going wrong with the mongodump utility, you will want to run a full backup again, because you will not be able to fully trust the dump which was created.
And a SIGPIPE is clearly a signal that something miserably went wrong. Here is does not matter if the network dived or whatever happened. From my impression mongodump should exit on a SIGPIPE ard definitely not ignore it.
At least it would be great if you could make this configurable and allow an option which make the tool listen to SIGPIPE because I think this will confuse a lot of people when they add mongodump into their backupchains...
What do you think?