[SERVER-27159] shell logs output of ReplicaSetMonitorWatcher with --quiet Created: 22/Nov/16  Updated: 23/Mar/23  Resolved: 03/Dec/21

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 3.2.10
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Andreas Kohn Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Fix Votes: 17
Labels: move-stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-33555 mongo --quiet does not silence initia... Closed
is duplicated by SERVER-38385 --quiet mongo shell option does not s... Closed
Related
is related to SERVER-23810 Don't Print Shell Log Messages to STD... Closed
is related to SERVER-4391 --eval should be affected by the --qu... Backlog
Assigned Teams:
Server Tooling & Methods
Operating System: ALL
Participants:
Case:

 Description   

I'm trying to get the primary currently used by a specific replica set in a shell script.

$ bin/mongo --host rs0/172.17.0.8,172.17.0.9,172.17.0.14 --quiet --eval 'var _s=rs.status(); if (typeof _s.members != "undefined") { _s.members.forEach(function (x) {if (x.stateStr=="PRIMARY") { print(x.name); }})}'
2016-11-22T17:06:58.396+0000 I NETWORK  [thread1] Starting new replica set monitor for rs0/172.17.0.14:27017,172.17.0.8:27017,172.17.0.9:27017
2016-11-22T17:06:58.397+0000 I NETWORK  [ReplicaSetMonitorWatcher] starting
2016-11-22T17:06:58.400+0000 I NETWORK  [thread1] changing hosts to rs0/mongodb-0.mongodb.default.svc.cluster.local:27017 from rs0/172.17.0.14:27017,172.17.0.8:27017,172.17.0.9:27017
mongodb-0.mongodb.default.svc.cluster.local:27017

The info/network messages there shouldn't be there, but they are now mixed with the output from the javascript evaluation. Minimally these messages should be on stderr, so that they can be filtered out easily.



 Comments   
Comment by Brooke Miller [ 03/Dec/21 ]

We've deprecated the mongo shell in favor of the new mongosh. Unfortunately, we aren't able to pursue improvements to the deprecated shell except in extreme cases, such as critical security fixes. Please start making use of mongosh and let us know if it works for you in this case.

Comment by Bernard Grymonpon [ 10/Feb/21 ]

If all error's can't be suppressed with the `–quiet` flag, could this be changed so all output from the shell itself is sent to stderr (or at least through a flag)? Simple scripting becomes very hard this way, tools like `jq` are commonly used but choke on these loglines... 

Comment by Cesar [ 10/Jun/19 ]

Hi,

Exists an effective workaround for this issue?

Its a bit hard to manage...

Regards,

Cesar Jorge

 

Comment by Alex Reece [ 08/Nov/17 ]

This issue prevents me from effectively writing scripts for mongo. At the very least, can these server messages get sent to stderr?

Comment by Andreas Kohn [ 18/Jan/17 ]

It only makes things slightly more complex ...

Maybe this at least helps as a starting point:

filter_mongodb_debug_messages() {
    # Workaround for https://jira.mongodb.org/browse/SERVER-27159
 
    grep -vE '^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}[+-][0-9]{4}\s+'
}
 
find_primary() {
    _maybe_primary=`((((mongo --host $1 --quiet --eval 'var _s=rs.status(); if (typeof _s.members != "undefined") { _s.members.forEach(function (x) {if (x.stateStr=="PRIMARY") { print(x.name); }})}' 2>/dev/null; echo $? >&3) | filter_mongodb_debug_messages >&4) 3>&1) | (read xs; exit $xs)) 4>&1`
    _result=$?
    if [ ${_result} -eq 0 ]; then
        echo ${_maybe_primary}
    else
        echo ""
    fi  
    exit ${_result}
}

The whole redirection magic is needed because we still need the error code from the command, not the error code of the filter.

Comment by Nick Thieling [ 17/Jan/17 ]

@Andreas I've been troubled by this problem as well. I don't want to write an filter around it to try to get rid of the extraneous output. I would hope that --quiet suppresses everything that isn't a halting error, and only returns the output if successfully run. Errors not being handled in a sensible way means I'd also have to write a filter to catch anything with "error"... boo

Comment by Andreas Kohn [ 10/Dec/16 ]

The problem is actually more generic: in another part of the script I did get output as well:

$ mongo --host 10.0.0.73 --quiet --eval 'print("cookie")' 2>/dev/null
2016-12-10T13:59:42.325+0000 W NETWORK  [thread1] Failed to connect to 10.0.0.73:27017, reason: errno:111 Connection refused
2016-12-10T13:59:42.325+0000 E QUERY    [thread1] Error: couldn't connect to server 10.0.0.73:27017, connection attempt failed :
connect@src/mongo/shell/mongo.js:231:14
@(connect):1:21

This is really problematic for using the shell for scripting. Error messages need to be sent to the standard error stream, not mixed with output from the commands itself.

Comment by Andreas Kohn [ 23/Nov/16 ]

Fair enough, that might make things a bit simpler. My code-snippet above comes from a bigger script, and the 'host' value is not always a replica set reference.

The problem with the log garbage still needs to be fixed though; for now I use a filter that removes all lines that look like MongoDB log output.

Comment by Asya Kamsky [ 23/Nov/16 ]

When you connect mongo shell to replica set (rs0/host1,host2...), the node it connects to will be the primary of the set.

So you can just print the name of the host shell is connected to when connection succeeds.

Generated at Thu Feb 08 04:14:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.