Hey *

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?

cheers
Jan