Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nethermind client should log when it auto-generates jwt-secret file #7747

Closed
obasekiosa opened this issue Nov 11, 2024 · 10 comments
Closed

Nethermind client should log when it auto-generates jwt-secret file #7747

obasekiosa opened this issue Nov 11, 2024 · 10 comments

Comments

@obasekiosa
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Right now the client only logs on start up when it doesn't see a keystore directory in the data directory and generates one.

It should log when it also generates a new jwt-secret file.

@MarekM25
Copy link
Contributor

@obasekiosa
Copy link
Contributor Author

obasekiosa commented Nov 22, 2024

https://github.com/NethermindEth/nethermind/blob/master/src/Nethermind/Nethermind.Core/Authentication/JwtAuthentication.cs#L48

Do we need something more?

When i ran the code, it seemed to silently do this, when it sees a keystore dir but no jwt-secret file.
it does log when there's no keystore dir

@obasekiosa
Copy link
Contributor Author

@ssonthal
want to try this?

@ssonthal
Copy link
Contributor

Sure. Will work on this.

@obasekiosa
Copy link
Contributor Author

obasekiosa commented Nov 22, 2024

Sure. Will work on this.

@ssonthal

so.
the first step is to reproduce the issue, especially because @MarekM25 thinks it's not an issue since there's reference code that should perform the expected action.

To reproduce:

  1. ensure keystore directory is deleted

  2. simply start a nethermind client (no need for consensus client, no need for change of data directory or setting JWTSecretFile option in config)

  3. check that the jwt-secret file is created and theres a log on console showing that.

  4. now shutdown the client and go into the keystore directory, delete the jwt-secret file.

  5. restart the client and repeat the check line 3.

PS: it's easier to search the log by dumping it into a file using <start_up_command> 2>&1 log_dump.log should work on most *unix shells and windows.

it could also be hard to keep track of when the logs get to the point of attempting sync, since you are redirecting the output to a file.
so you could just open another terminal and follow the dump file tail -f log-dump.log.

then search the file.

@ssonthal
Copy link
Contributor

ssonthal commented Nov 22, 2024

Hey @MarekM25 / @obasekiosa

I could reproduce this issue locally. Here's a screenshot of the logs after:

  1. running the client
  2. verifying that jwt-secret file exists at Nethermind.Runner/keystore path.
  3. shutting down the client
  4. deleting the jwt-secret file at keystore
  5. restarting the client.

Screenshot 2024-11-22 at 10 54 24 PM

As you can see the jwt-secret was auto-generated by the client but no warning logs appeared.

@obasekiosa
Copy link
Contributor Author

Hey @MarekM25 / @obasekiosa

I could reproduce this issue locally. Here's a screenshot of the logs after:

  1. running the client
  2. verifying that jwt-secret file exists at Nethermind.Runner/keystore path.
  3. shutting down the client
  4. deleting the jwt-secret file at keystore
  5. restarting the client.

Screenshot 2024-11-22 at 10 54 24 PM

As you can see the jwt-secret was auto-generated by the client but no warning logs appeared.

Nice!

So the expected log level should be info not warning.

The default level of logs displayed by the client is info

now that you know this and can reproduce it, you could attempt finding out what the issue is
then how to fix it.
could start by looking for the code that regenerates the file, and then also the link @MarekM25 posted

another place to check is the location of the code that logs the "Reading authentication secret..." line of the logs.

good luck.

@ssonthal
Copy link
Contributor

Hey @obasekiosa , I must have done something wrong the prev time. I tried multiple time to reproduce that issue again. but it seems to be logging the msgs fine. Tried thrice after the first attempt.

Screenshot 2024-11-22 at 11 28 28 PM

@obasekiosa
Copy link
Contributor Author

Hey @obasekiosa , I must have done something wrong the prev time. I tried multiple time to reproduce that issue again. but it seems to be logging the msgs fine. Tried thrice after the first attempt.

Screenshot 2024-11-22 at 11 28 28 PM

@ssonthal
looking at your log, i can see what the issue is.

its being logged as a warning. (colored)
Seems your log level is now higher than info.

in the mean time wanna try 7748

I'll close this as closed

@obasekiosa
Copy link
Contributor Author

closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants