I tried to configure uWSGI’s listen backlog from the kernel’s own setting:
--listen=@(/proc/sys/net/core/somaxconn)The value came back empty. The file had content when read normally, but its reported size was zero. uWSGI’s simple-file reader used the stat size to decide how much data to read, so it read none.
The issue reached an assumption below the configuration syntax. @(...) was doing its job of selecting an address. The reader underneath it treated a filesystem metadata value as the complete length of the stream that opening that address would produce.
That works for many ordinary files. procfs can generate content at read time, and its st_size does not have to describe those bytes. A reader that supports such a source has to keep reading until EOF rather than using zero metadata length as evidence of an empty result.
Upstream fixed the reader. My confirmation also tested obtaining the same listen value through an HTTP address. The repair preserved the general address-indirection path; it did not add a special parser for one kernel setting.
The same reader also powered uWSGI’s --extract, so repairing its EOF handling corrected more than the listen-setting lookup.