Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-47593

cbcollect_info - few files are 0 bytes in cbcollect zip



    • Untriaged
    • 1
    • Yes


      I found some oddity that shows up when trying to create a backport for MB-47380 into 7.0.1.
      MB-47380 has been fine and it still works fine in master.

      However, once cherry-picked the portions to CC, re-running cbcollect (without redaction) ends up with empty files that MB-47380 added... namely, goxdcr_remote_clusters.json and goxdcr_replications.json.

      Spoke with Steve Watanabe, and he pointed me to a few check-ins lately that also touched cbcollect_info. Namely:

      Interestingly, when I reverted http://review.couchbase.org/c/ns_server/+/157902 patch locally, the cbcollect works, which means that the newly added XDCR files have content in them.

      It also seems like the same situation of 0 byte files in the zip file also occurs to at least one other file. One other example I found used a similar syntax as the new goxdcr files being generated. Specifically, the entry:

              make_curl_task(name="master events",
                             url='http://%s:%s/diag/masterEvents?o=1' % (
                                 local_url_addr, read_guts(guts, "rest_port")),

      (And another non-text file, projector_cprof.log)

      Ultimately, without reverting the patch, the 2 goxdcr files + the master_events.log + projector_cprof.log are empty in the zip file. And, reverting the patch seems to flush them just fine (non-0 bytes and with valid data). Thus, I don't think it is specific only to goxdcr portion of the log collection.

      Visually, I think the patch looks fine, and atm I don't see anything wrong with it.

      What's weird is also the fact that all 3 patches (the 2 mentioned above + goxdcr's portion) are present in master, and cbcollect_info runs just fine in master.
      File size was a thought, but there are other small files that were flushed just fine with the changeset.
      File descriptor count doesn't seem to be a problem, as ulimit -n is big enough on my machine.


        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.


            neil.huang Neil Huang created issue -
            neil.huang Neil Huang made changes -
            Field Original Value New Value
            Link This issue relates to MB-47521 [ MB-47521 ]
            meni.hillel Meni Hillel (Inactive) made changes -
            Assignee Aliaksey Artamonau [ aliaksey artamonau ] Steve Watanabe [ steve.watanabe ]
            steve.watanabe Steve Watanabe made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            steve.watanabe Steve Watanabe made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            lynn.straus Lynn Straus made changes -
            Fix Version/s 7.0.2 [ 18012 ]
            lynn.straus Lynn Straus made changes -
            Fix Version/s 7.0.1 [ 17104 ]
            Balakumaran.Gopal Balakumaran Gopal made changes -
            Labels request-dev-verify
            meni.hillel Meni Hillel (Inactive) made changes -
            Status Resolved [ 5 ] Closed [ 6 ]


              steve.watanabe Steve Watanabe
              neil.huang Neil Huang
              0 Vote for this issue
              3 Start watching this issue



                Gerrit Reviews

                  There are no open Gerrit changes