Yonghao Zou

It should work, can you paste your code?

Any updates for this?

> Hi, Yes, you're correct. DMTCP does not support Valgrind. It's because both are doing things at a low level, and they interfere with each other. Some other tools that...

Same for me. ``` /* TODO does not work */ ```

@chenzhangyi 访问step down的节点的/raft_stat也会超时，但是其他节点看起来都正常 ``` [Atomic] peer_id: 127.0.1.1:8301:0 state: FOLLOWER readonly: 0 term: 5 conf_index: 3 peers: 127.0.1.1:8300:0 127.0.1.1:8301:0 127.0.1.1:8302:0 127.0.1.1:8303:0 127.0.1.1:8304:0 leader: 127.0.1.1:8303:0 last_msg_to_now: 19 election_timer: timeout(200ms) SCHEDULING(in 259ms) vote_timer:...

> pstack下，这种应该就是卡死了 我尝试在出现`step down`时保留现场，但是`pstack` 一直显示 `Operation not permitted.`，即使使用root权限也不行。 但是使用`strace`可以看到该进程还在进行一些读取`/proc/self/stat`之类的操作。 客户端如果访问的第一个节点不是`step down`的那个节点的话，可以拿到数据，但是如果第一个节点是那个节点，就会超时。 `step down`节点的`raft_stat`依然无法显示，访问会超时。

这个bug有可能在example的例子里面复现么

> 一般情况下，选举时间需要远大于 RTT，不然选注和心跳都难以维持。 > 不过这个问题里“C的选举超时时间一段时间内小于A B”这个是什么原因？ > > PS：可以看看是不是把C的选举超时时间调大 这里是为了测试而故意设定的，发现这种情况下一直无法稳定选举，虽然A B一直是正常的。

> > > 一般情况下，选举时间需要远大于 RTT，不然选注和心跳都难以维持。 > > > 不过这个问题里“C的选举超时时间一段时间内小于A B”这个是什么原因？ > > > PS：可以看看是不是把C的选举超时时间调大 > > > > > > 这里是为了测试而故意设定的，发现这种情况下一直无法稳定选举，虽然A B一直是正常的。 > > 不知道你们测试这种case的用意是什么，但是按照描述，这里的行为符合预期。因为C的超时时间短，所以它天然会比其它节点更快触发选注 主要是想测试一些极端情况下的问题，目前这种情况确实出现几率非常低，不过如果能改善就更好了。

> This requires us to run the `php flarum blomstra:search:build` command for each forum, so that the search dataset can be built. Further posts and discussions will be added manually,...