Apply suggestions from code review

Co-authored-by: Marcin Rataj <[email protected]>

Author: 2color

docs/how-to/troubleshooting-kubo.md

@@ -104,7 +104,7 @@ You should see the peer ID of `node a` printed out.
 
 If this command returns nothing (or returns IDs that are not `node a`), then no record of node `a` being a provider for the CID. This can happen if the data is added while `node a` does not have a daemon running. 
 
-If this happens, you can the `ipfs routing provide <cid>` command on `node a` to announce to the network that you have that CID:
+If this happens, and you don't want to wait for [`Reprovider.Interval`](https://github.com/ipfs/kubo/blob/master/docs/config.md#reproviderinterval) to trigger, you can use the `ipfs routing provide <cid>` command on `node a` to manually announce to the network that you have that CID:
 
 ```shell
 ipfs routing provide <cid>
@@ -161,78 +161,5 @@ When you see ipfs doing something (using lots of CPU, memory, or otherwise being
 
 There's a command (`ipfs diag profile`) that will do this for you and bundle the results up into a zip file, ready to be attached to a bug report.
 
-If you feel intrepid, you can dump this information and investigate it yourself:
-
-1. goroutine dump:
-
-    ```shell
-    curl localhost:5001/debug/pprof/goroutine\?debug=2 > ipfs.stacks
-    ```
-
-1. 30-second cpu profile:
-
-    ```shell
-    curl localhost:5001/debug/pprof/profile > ipfs.cpuprof
-    ```
-
-1. heap trace dump:
-
-    ```shell
-    curl localhost:5001/debug/pprof/heap > ipfs.heap
-    ```
-
-1. memory statistics. In JSON see `memstats` object:
-
-    ```shell
-    curl localhost:5001/debug/vars > ipfs.vars
-    ```
-
-1. System information:
-
-    ```shell
-    ipfs diag sys > ipfs.sysinfo
-    ```
-
-### Analyzing the stack dump
-
-The first thing to look for is hung goroutines - any goroutine that's been stuck for over a minute will note that in the trace. It looks something like:
-
-```shell
-goroutine 2306090 [semacquire, 458 minutes]:
-sync.runtime_Semacquire(0xc8222fd3e4)
-    /home/whyrusleeping/go/src/runtime/sema.go:47 +0x26
-sync.(*Mutex).Lock(0xc8222fd3e0)
-    /home/whyrusleeping/go/src/sync/mutex.go:83 +0x1c4
-gx/ipfs/QmedFDs1WHcv3bcknfo64dw4mT1112yptW1H65Y2Wc7KTV/yamux.(*Session).Close(0xc8222fd340, 0x0, 0x0)
-    /home/whyrusleeping/gopkg/src/gx/ipfs/QmedFDs1WHcv3bcknfo64dw4mT1112yptW1H65Y2Wc7KTV/yamux/session.go:205 +0x55
-gx/ipfs/QmWSJzRkCMJFHYUQZxKwPX8WA7XipaPtfiwMPARP51ymfn/go-stream-muxer/yamux.(*conn).Close(0xc8222fd340, 0x0, 0x0)
-    /home/whyrusleeping/gopkg/src/gx/ipfs/QmWSJzRkCMJFHYUQZxKwPX8WA7XipaPtfiwMPARP51ymfn/go-stream-muxer/yamux/yamux.go:39 +0x2d
-gx/ipfs/QmZK81vcgMhpb2t7GNbozk7qzt6Rj4zFqitpvsWT9mduW8/go-peerstream.(*Conn).Close(0xc8257a2000, 0x0, 0x0)
-    /home/whyrusleeping/gopkg/src/gx/ipfs/QmZK81vcgMhpb2t7GNbozk7qzt6Rj4zFqitpvsWT9mduW8/go-peerstream/conn.go:156 +0x1f2
-    created by gx/ipfs/QmZK81vcgMhpb2t7GNbozk7qzt6Rj4zFqitpvsWT9mduW8/go-peerstream.(*Conn).GoClose
-    /home/whyrusleeping/gopkg/src/gx/ipfs/QmZK81vcgMhpb2t7GNbozk7qzt6Rj4zFqitpvsWT9mduW8/go-peerstream/conn.go:131 +0xab
-```
-
-At the top, you can see that this goroutine (number 2306090) has been waiting to acquire a semaphore for 458 minutes. That seems bad. Looking at the rest of the trace, we see the exact line it's waiting on is line 47 of runtime/sema.go. That's not particularly helpful, so we move on. Next, we see that call was made by line 205 of yamux/session.go in the `Close` method of `yamux.Session`. This one appears to be the issue.
-
-Given that information, look for another goroutine that might be holding the semaphore in question in the rest of the stack dump.
-
-There are a few different reasons that goroutines can be hung:
-
-- `semacquire` means we're waiting to take a lock or semaphore.
-- `select` means that the goroutine is hanging in a select statement, and none of the cases are yielding anything.
-- `chan receive` and `chan send` are waiting for a channel to be received from or sent on, respectively.
-- `IO wait` generally means that we are waiting on a socket to read or write data, although it *can* mean we are waiting on a very slow filesystem.
-
-If you see any of those tags _without_ a `, X minutes` suffix, that generally means there isn't a problem -- you just caught that goroutine in the middle of a short wait for something. If the wait time is over a few minutes, that either means that goroutine doesn't do much, or something is pretty wrong.
-
-If you see a lot of goroutines, consider using [stackparse](https://github.com/whyrusleeping/stackparse) to filter, sort, and summarize them.
-
-### Analyzing the CPU Profile
-
-The go team wrote an [excellent article on profiling go programs](http://blog.golang.org/profiling-go-programs). If you've already gathered the above information, you can skip down to where they start talking about `go tool pprof`. My go-to method of analyzing these is to run the `web` command, which generates an SVG dotgraph and opens it in your browser. This is the quickest way to easily point out where the hot spots in the code are.
-
-### Analyzing vars and memory statistics
-
-The output is JSON formatted and includes badger store statistics, the command line run, and the output from Go's [runtime.ReadMemStats](https://golang.org/pkg/runtime/#ReadMemStats). The [MemStats](https://golang.org/pkg/runtime/#MemStats) has useful information about memory allocation and garbage collection.
+If you feel intrepid, you can dump this information and investigate it yourself by following the [Advanced Kubo Debug Guide at GitHub](https://github.com/ipfs/kubo/blob/master/docs/debug-guide.md).
 

docs/reference/diagnostic-tools.md

@@ -39,7 +39,7 @@ Learn more about CID concepts, including components and versions in the [content
 
 ## Helia Identify
 
-[Helia Identify](https://ipfs.fyi/identify) is a browser-based tool to run libp2p identify with Peer IDs / multiaddrs, testing whether an IPFS peer is Web friendly, i.e. whether it can be connected to from a browser. This is useful to test whether content can be directly retrieved from a provider node.
+[Helia Identify](https://ipfs.fyi/identify) is a browser-based tool to run [libp2p identify](https://github.com/libp2p/specs/blob/master/identify/README.md) with Peer IDs / multiaddrs, testing whether an IPFS peer is Web friendly, i.e. whether it can be connected to from a browser. This is useful to test whether content can be directly retrieved from a provider node.
 
 ## IPFS Gateway Checker