How to deal with a pre-packaged program not adhering to the Rule of Silence?

Question

Concrete problem:

Mailman comes with a script to synchronize mailing list subscribers from a flat file (sync_members(8)).

This script does not very well adhere to the Rule of Silence. For example, when there is nothing to do (e.g. the current subscribers and the flat file are the same) it prints "Nothing to do." to stdout.

As we're running this program every few minutes and any output is logged to our log server (with rsyslogd) which then sents daily emails with the logs there tend to be a lot of useless messages in it.

There are several ways to deal with this, and I'm wondering which one is the most appropriate one:

1. Pipe stdout to /dev/null.
2. Use rsyslogd filtering to specifically filter out these messages.
3. Modify the source code of sync_members to adhere to the Rule of Silence.
4. Copy the source code of sync_members, modify the copy and use that one from now on.

While each would achieve the desired result, each has its disadvantages:

1. What if at some time there's something interesting on stdout?
2. Seems a rather "unclean" and "hackerish" solution, and I daresay there are a lot of programs our there not adhering to the Rule of Silence.
3. What happens if there's an update?
4. Same as 3.

I tend to option 2, though if I have to do this for every badly behaved program in our system...

What do you think? Is there an additional option or argument in favor or against? Is there a best practice for this case (I daresay this problem is not new)?

Answer 1

Two suggestions:

1. File a bug report against mailman, so the developer can fix the bug for everyone.

2. Change the synch_members call to synch_members | egrep -v "Nothing to do." That will eliminate the "Nothing to do." messages.

Answer 2

You're missing option 5: write a wrapper script that redirects the output of sync_members and checks whether or not it's "Nothing to do.".

With proper exit code checking, this could do the job pretty well. It is relatively upgrade safe - as long as the "nothing" message doesn't change, your script doesn't have to be maintained.

And you can decide how to handle error cases in that script (i.e. just cat the log file, or do something more interesting).

Answer 3

If "Nothing to do" doesn't vary (or can be brought down to a regex), you could use grep like this:

    grep -v "Nothing to do" *.log

From here on there are plenty of things you could do to solve your problem:

• redirect the output of the above command to create new "silent" logs.
• define functions and aliases based on the above command to use as shortcuts in your interactive sessions (You could even define "Nothing to do as an environment variable).
• define cron jobs that will automate the execution of such commands at regular intervals.

A lot could be done with the basic Unix tools and a modern shell. I think it's a bit too early to decide to modify a source code. Keep it simple, it will avoid a lot of wasted time.