erlang/otp

Describe the bug We first encountered this problem while investigating scheduler utilization in our self-managed Kubernetes cluster. We then reproduced it in a Docker container with a CPU quota, as shown below. scheduler:utilization/2 calculates weighted using erlang:system_info(logical_processors_available) (LPA), without accounting for erlang:system_info(cpu_quota). When a container's CPU quota is smaller than its visible CPU set, the result understates scheduler utilization relative to the container's detected CPU capacity. For example, with LPA=8 and quota=1, one fully active normal scheduler and one idle dirty CPU scheduler produce weighted = 12.5%. Normalizing the same scheduler activity by the one-CPU quota gives 100%. To reproduce Run this on a Linux Docker host with at least two CPUs available to the container. The command applies a one-CPU quota without restricting the CPU set, starts a CPU-bound Erlang process, and samples utilization over two seconds. docker run --rm --netw

Is your feature request related to a problem? Please describe. Currently, there is no documented way to see how much data is queued for sending on a distribution connection. When a connection gets congested, the only signal is the busy_dist_port system monitor/trace event, and that fires only once a sender is already being suspended. You can't watch a queue grow toward dist_buf_busy_limit. Describe the solution you'd like A public API to read a distribution queue size. Additional context I know some libraries work around this with internals. For example, observer_cli does something like: get_dist_queue_size(Node) -> case ets:lookup(sys_dist, Node) of [] -> not_found; [Connection] -> %% Element 3 of net_kernel's #connection{} record is the %% connection's distribution handle DHandle = element(3, Connection), {ok, _In, _Out, QueuedBytes} = erlang:dist_get_stat(DHandle), QueuedBytes end. Three

Describe the bug logger_h_common sends every 21st write synchronously. The synchronous log path in the file_ctrl_loop always does a file_check. See here. Expected behavior logger respects the file_check configuration and only does file_check once the interval has passed. Additional context Found this while tuning file_check in a real system and observing syscalls. I expected configuring file_check to heavily reduce the amount of times file_check is called, but on high throughput systems, it makes very little difference because the synchronous path behaviour. If intentional, I think this should be documented. If not, the fix is simply removing the ensure_file call from the sync log, since write_to_dev already conditionally calls ensure_file if the file_check window has passed.

Describe the bug ODBC_CAN_BUILD_DRIVER=true must be specified via an environment variable in order to compile odbcserver such that it gets installed with erlang/otp and thus can go into a release for an application. To Reproduce git checkout OTP-29.1.1 && git clean -xfd && ./configure --with-odbc && make -j && make release && f=$(find release -name odbcserver -print -quit) && [ -n "$f" ] && echo "FOUND : $f" || echo "ERROR: odbcserver not found" Observe "ERROR: odbcserver not found" Then : export ODBC_CAN_BUILD_DRIVER=true && git checkout OTP-29.1.1 && git clean -xfd && ./configure --with-odbc && make -j && make release && f=$(find release -name odbcserver -print -quit) && [ -n "$f" ] && echo "FOUND : $f" || echo "ERROR: odbcserver not found" Expected behavior When --with-odbc switch is given odbcserver is compiled and can be installed during the life time of OTP 29. Affected versions OTP >= 29.0 Additional context N/A

Describe the bug logger:remove_handler/1 can drop a different handler that was added at about the same time. The dropped handler keeps its config (logger:get_handler_config/1 answers {ok, _}), but it is gone from the primary handlers list, so its log/2 is never called. The cause is in lib/kernel/src/logger_server.erl, handle_call({remove_handler,HandlerId}, ...): {ok,Config} = logger_config:get(Tid,primary), Handlers0 = maps:get(handlers,Config,[]), Handlers = lists:delete(HandlerId,Handlers0), call_h_async( fun() -> call_h(Module,removing_handler,[HConfig],ok) end, fun(_Res) -> logger_config:set(Tid,primary,Config#{handlers=>Handlers}), logger_config:delete(Tid,HandlerId), ok end,From,State); Config and Handlers are read when the request arrives. When another async request is in flight, call_h_async/4 queues the two funs, and the post fun runs later with that stale Config. Any add_handler that completed in between is overwritten: the post fun of add