Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.0.1
-
Untriaged
-
1
-
Yes
Description
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:
http://review.couchbase.org/c/ns_server/+/157902
and
http://review.couchbase.org/c/ns_server/+/157903
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",
|
user="@",
|
password=memcached_pass,
|
timeout=300,
|
url='http://%s:%s/diag/masterEvents?o=1' % (
|
local_url_addr, read_guts(guts, "rest_port")),
|
log_file="master_events.log",
|
no_header=True),
|
(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.
Attachments
Issue Links
- relates to
-
MB-47521 [BP 7.0.2] - XDCR - collect remote clusters and replication info as part of cbcollect
-
- Closed
-