kucharskim
Repos
21
Followers
10
Following
5

Events

Created at 9 hours ago
opened issue
Report AppName during startup of the application - it helps

I think app name changed from ag0 to agd and hence env variables which override config also changed. It took me too much time to figure that out, if just the app could print early on startup what is its app name.

Created at 1 day ago
opened issue
Peggo monitoring - health endpoint with HTTP 200

Health endpoint with HTTP 200 or embedded Prometheus exporter

Probably duplicate of https://github.com/InjectiveLabs/injective-chain-releases/issues/47

Created at 1 week ago
Peggo monitoring - health endpoint with HTTP 200

Health endpoint with HTTP 200 or embedded Prometheus exporter.

Created at 1 week ago
issue comment
Protocol upgrade related metrics

Which nearcore release this is going to be included in?

Created at 1 month ago
issue comment
Expose ProtocolUpgradeVotingSchedule via an RPC endpoint

Thanks!

Created at 1 month ago
issue comment
Expose ProtocolUpgradeVotingSchedule via an RPC endpoint

How we are creating alarms for example for expired TLS certificates, metric value is timestamp, so when timestamp is less than a week from time() trigger the alarm. I was looking for something like that here.

Created at 1 month ago
issue comment
Expose ProtocolUpgradeVotingSchedule via an RPC endpoint

Sure, yeah. That would be even better. I wouldn't mind if it would be both, as I usually by hand more spent time looking at json rpc outputs from near than prometheus metrics.

Created at 1 month ago
issue comment
Expose ProtocolUpgradeVotingSchedule via an RPC endpoint

So, I don't need to look into source code to know. For monitoring purposes. I would like to see the deadline in Prometheus. I could update one RPC node early and get highest protocol version and date into Prometheus and have alarms based on that.

In perfect scenario, chain would have that info, and having metric for it no matter what version of neard you are running would be even better.

Basically it would help me from operational perspective.

Created at 1 month ago
issue comment
Fix a typo in rset(1)

As in, please don't merge yet.

Created at 1 month ago
issue comment
Fix a typo in rset(1)

Let me look into it more. Thanks!

Created at 1 month ago
started
Created at 1 month ago
pull request opened
Fix a typo in rset(1)
Created at 1 month ago

s/tern/turn/

Created at 1 month ago
Created at 1 month ago
issue comment
node_key missing in /status endpoint for non-validator nodes

Then why you created public_addrs in the first place? Keep it simple then and drop the req of node key there.

Created at 1 month ago
issue comment
node_key missing in /status endpoint for non-validator nodes

This is super confusing and in long run, as painful as it is, I would break people scripts, but scream loud that this is going to happen.

Created at 1 month ago
issue comment
node_key missing in /status endpoint for non-validator nodes

Shoot. I didn't even notice. I would change this and drop node_key for 2 mainnet releases and scream out loud on Telegram, Discord, email and release notes that node_key is renamed to validator_key (names based on settings in config.json without _file suffix). Then 2 releases later would introduce node_key back as content of the node key. However the question is then, what do expect people to put into public_addrs - the node key or validator key? I thought all this time that node key was added to /status endpoint because of public_addrs content.

Created at 1 month ago
issue comment
thread 'actix-rt|system:0|arbiter:0' panicked at 'called `Option::unwrap()` on a `None` value', chain/chain/src/chain.rs:2495:57

@mzhangmzz I'm aware. What I am reporting here is process panicked. That should not happen, no matter what is going on on the chain. This can be used as DDoS.

Created at 1 month ago
issue comment
thread 'actix-rt|system:0|arbiter:0' panicked at 'called `Option::unwrap()` on a `None` value', chain/chain/src/chain.rs:2495:57

..and I cannot really take status page as it's constantly timing out: `` mikolaj@sandbox02:~$ time curl -m120 -sSf localhost:3030/status | jq -r . curl: (28) Operation timed out after 120001 milliseconds with 0 bytes received

real 2m0.013s user 0m0.046s sys 0m0.009s


I tried even longer timeouts and no luck.
                                
Created at 1 month ago
issue comment
thread 'actix-rt|system:0|arbiter:0' panicked at 'called `Option::unwrap()` on a `None` value', chain/chain/src/chain.rs:2495:57

This is from testnet machine.

$ /data/neard/neard --version
neard (release 1.30.0-rc.2) (build 1.30.0-rc.2) (rustc 1.63.0) (protocol 57) (db 31)
Created at 1 month ago
opened issue
thread 'actix-rt|system:0|arbiter:0' panicked at 'called `Option::unwrap()` on a `None` value', chain/chain/src/chain.rs:2495:57
Oct 13 00:43:49 sandbox02 neard[1185538]: 102465065 4hkuea6ZsywcDTex3QTJSttFE18zzh9AeymoKoaWHcHD Processed in progress for 12461994ms orphan for 469ms  Chunks:(X✔✔✔))
Oct 13 00:43:53 sandbox02 neard[1185538]: thread 'actix-rt|system:0|arbiter:0' panicked at 'called `Option::unwrap()` on a `None` value', chain/chain/src/chain.rs:2495:57
Oct 13 00:43:53 sandbox02 neard[1185538]: stack backtrace:
Oct 13 00:43:53 sandbox02 neard[1185538]:    0: rust_begin_unwind
Oct 13 00:43:53 sandbox02 neard[1185538]:              at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
Oct 13 00:43:53 sandbox02 neard[1185538]:    1: core::panicking::panic_fmt
Oct 13 00:43:53 sandbox02 neard[1185538]:              at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
Oct 13 00:43:53 sandbox02 neard[1185538]:    2: core::panicking::panic
Oct 13 00:43:53 sandbox02 neard[1185538]:              at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:48:5
Oct 13 00:43:53 sandbox02 neard[1185538]:    3: near_chain::chain::Chain::check_orphans
Oct 13 00:43:53 sandbox02 neard[1185538]:    4: near_chain::chain::Chain::postprocess_ready_blocks
Oct 13 00:43:53 sandbox02 neard[1185538]:    5: near_client::client_actor::ClientActor::try_process_unfinished_blocks
Oct 13 00:43:53 sandbox02 neard[1185538]:    6: near_client::client_actor::ClientActor::check_triggers
Oct 13 00:43:53 sandbox02 neard[1185538]:    7: <near_client::client_actor::ClientActor as actix::handler::Handler<near_network::types::NetworkClientMessages>>::handle
Oct 13 00:43:53 sandbox02 neard[1185538]:    8: <actix::address::envelope::SyncEnvelopeProxy<M> as actix::address::envelope::EnvelopeProxy<A>>::handle
Oct 13 00:43:53 sandbox02 neard[1185538]:    9: <actix::contextimpl::ContextFut<A,C> as core::future::future::Future>::poll
Oct 13 00:43:53 sandbox02 neard[1185538]:   10: tokio::runtime::task::raw::poll
Oct 13 00:43:53 sandbox02 neard[1185538]:   11: tokio::task::local::LocalSet::tick
Oct 13 00:43:53 sandbox02 neard[1185538]:   12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
Oct 13 00:43:53 sandbox02 neard[1185538]: note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Oct 13 00:43:53 sandbox02 systemd[1]: neard.service: Main process exited, code=killed, status=6/ABRT
Created at 1 month ago
opened issue
Expose ProtocolUpgradeVotingSchedule via an RPC endpoint

Expose ProtocolUpgradeVotingSchedule via an RPC endpoint like /status. I think something along the lines of: {"proto": 56, "timestamp": "2022-09-28T15:00:00Z"} would be good enough for me.

Ref https://github.com/near/nearcore/commit/cdebd3fa2cf516f0b672710c404718c331dd1b07

Created at 2 months ago
opened issue
node_key missing in /status endpoint for non-validator nodes

Under /status endpoint, .node_key is missing for an RPC node. At present, from my observation, only Validators have .node_key present. I think all nodes should have that json entry, no matter are they validator, or not.

$ curl -s validator:3030/status | jq -r .version  
{
  "version": "1.29.0",
  "build": "1.29.0",
  "rustc_version": "1.62.1"
}

$ curl -s validator:3030/status | jq -r .node_key
ed25519:5Y9hW8cKBb5RnsJBqttHHC5ujz5zcZZ5xnrJPwkCWmGQ
$ curl -s rpc:3030/status | jq -r .version  
{
  "version": "1.29.0",
  "build": "1.29.0",
  "rustc_version": "1.62.1"
}

$ curl -s rpc:3030/status | jq -r .node_key
null

From above output my expectation from operational perspective would be that all nodes would return public part of node key via curl -s rpc:3030/status | jq -r .node_key however non-validators return null.

Created at 2 months ago
issue comment
forward email with srs - is this possible?

Hi, Did you manage to do this?

No I didn't, as I didn't had time to look deeper. I would need to setup testing domain and spare smtpd(8) machine to test more, but so far I didn't had time. Setup of SRS and apply it for specific domain and specific user mapping, is something which I don't know how to do.

Created at 2 months ago