Describe the bug
On the posix platform, ot-daemon -d <level> (and ot-cli -d <level>) does not change the log level. The process keeps logging at OPENTHREAD_CONFIG_LOG_LEVEL_INIT, which openthread-core-posix-config.h sets to OT_LOG_LEVEL_CRIT, whatever is passed.
The cause is an ordering problem in src/posix/main.c, InitInstance():
IgnoreError(otLoggingSetLevel(aConfig->mLogLevel));
instance = otSysInit(&aConfig->mPlatformConfig);
In a single-instance build otLoggingSetLevel() is Instance::Get().SetLogLevel(level), and Instance::Get() returns the raw static buffer. At this point no Instance has been constructed in it yet, so SetLogLevel() writes mLogLevel into uninitialised storage (and calls SignalLogLevelChange() on it). otSysInit() then reaches Instance::InitSingle(), whose placement-new runs the constructor:
, mLogLevel(static_cast<LogLevel>(OPENTHREAD_CONFIG_LOG_LEVEL_INIT))
which puts the level back to CRIT. The value from -d is lost, and because of IgnoreError nothing reports it.
To Reproduce
Commit 87e6c37, macOS 26 (arm64); nothing in the path above is platform-specific.
- Build the posix daemon with
-DOT_LOG_LEVEL=DEBG -DOT_FULL_LOGS=ON.
sudo ot-daemon -v -d 4 'spinel+hdlc+forkpty://<ot-rcp>?forkpty-arg=1', then form a network with ot-ctl.
- Only the four
syslog(LOG_INFO, ...) lines from main.c appear (Running ..., Thread version, Thread interface, RCP version); no core log lines at all.
- After
ot-ctl log level 4 the core logs appear as expected.
Expected behavior
-d <level> sets the initial log level. Calling otLoggingSetLevel() after otSysInit() returns would do it, at the cost of the log lines emitted during otSysInit() itself; alternatively the level could be carried into the instance another way. Happy to send a PR for whichever you prefer.
Values above 5 (e.g. -d 7, a habit from otbr-agent) are rejected by SetLogLevel() with kErrorInvalidArgs, which is also swallowed by the IgnoreError; a warning there would help.
Additional context
Possibly related, but not root-caused: in the same setup, raising the level to debug at run time with ot-ctl log level 5 was followed by the daemon going away. The last line it logged was [D] Cli-----------: Output: Done, after which every ot-ctl call got connect session failed: Connection refused; no crash report was written. ot-ctl log level 4 does not have this effect. I have seen this once and have not investigated further, so please treat it as an observation rather than a diagnosis; I can open a separate issue with a proper reproduction if that is useful.
Describe the bug
On the posix platform,
ot-daemon -d <level>(andot-cli -d <level>) does not change the log level. The process keeps logging atOPENTHREAD_CONFIG_LOG_LEVEL_INIT, whichopenthread-core-posix-config.hsets toOT_LOG_LEVEL_CRIT, whatever is passed.The cause is an ordering problem in
src/posix/main.c,InitInstance():In a single-instance build
otLoggingSetLevel()isInstance::Get().SetLogLevel(level), andInstance::Get()returns the raw static buffer. At this point noInstancehas been constructed in it yet, soSetLogLevel()writesmLogLevelinto uninitialised storage (and callsSignalLogLevelChange()on it).otSysInit()then reachesInstance::InitSingle(), whose placement-new runs the constructor:which puts the level back to
CRIT. The value from-dis lost, and because ofIgnoreErrornothing reports it.To Reproduce
Commit 87e6c37, macOS 26 (arm64); nothing in the path above is platform-specific.
-DOT_LOG_LEVEL=DEBG -DOT_FULL_LOGS=ON.sudo ot-daemon -v -d 4 'spinel+hdlc+forkpty://<ot-rcp>?forkpty-arg=1', then form a network withot-ctl.syslog(LOG_INFO, ...)lines frommain.cappear (Running ...,Thread version,Thread interface,RCP version); no core log lines at all.ot-ctl log level 4the core logs appear as expected.Expected behavior
-d <level>sets the initial log level. CallingotLoggingSetLevel()afterotSysInit()returns would do it, at the cost of the log lines emitted duringotSysInit()itself; alternatively the level could be carried into the instance another way. Happy to send a PR for whichever you prefer.Values above
5(e.g.-d 7, a habit fromotbr-agent) are rejected bySetLogLevel()withkErrorInvalidArgs, which is also swallowed by theIgnoreError; a warning there would help.Additional context
Possibly related, but not root-caused: in the same setup, raising the level to debug at run time with
ot-ctl log level 5was followed by the daemon going away. The last line it logged was[D] Cli-----------: Output: Done, after which everyot-ctlcall gotconnect session failed: Connection refused; no crash report was written.ot-ctl log level 4does not have this effect. I have seen this once and have not investigated further, so please treat it as an observation rather than a diagnosis; I can open a separate issue with a proper reproduction if that is useful.