I found the problem, sn_launch_tool seems to be clobbering the RUST_LOG environment variable via the --rust_log flag.
My short term fix was to remove that flag entirely from sn_launch_tool, but I’ll come up with a cleaner fix in a future PR.
My thinking-out-load thinks this line is missing a check for the actual environment variable (it only checks for the flag):
and then this line seals the fate, ignoring any ‘real’ environment variable that was set:
I was trying to change the sn_node init_logging to a hardcoded filter level, but a) the launcher was always overriding it with the RUST_LOG environment variable, and b) RUST_LOG was only loaded from the flag (never the environment).
Ah right, the idea behind all that was that RUST_LOG would apply only to the app you are effectively running, in this case the launch_tool, but that doesn’t necessarily mean it’s the log level you want for the sn-nodes being launched by it. So that was an attempt to make that separation. Since as you say it’s confusing, it’s probably ok to have both the tool and nodes being launched to all go with the same level which is just from RUST_LOG I guess…
Yes, I agree. We are on the same page, I was just trying to point out that the CLI -y flag actually ends up setting the -y flag in the launch tool here, which is done from here, that’s how it’s been supported till now. So we can change them as you describe, the -y is very confusing. It’ll be different though as the new --node-verbosity will expect a RUST_LOG value while the existing -y is just mapping from occurrences to log levels, but I don’t think we need that if we have all the power of the RUST_LOG value.
The hardcoded -v is for having the launch-tool to print out the messages about the nodes being launched and so forth on the stdout.