You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
http'server 'listen on unix_sock should throw a error IF the-input-sockname-length EXCEED the maximum linux-limit #48316
//suppose a-very-long-absolute-path is used
var WORKDIR = "/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_093430_074_4211____nv_cli_how_many_workers___/"
fs.mkdirSync(WORKDIR);
/*
> console.log(child_process.execSync("pwd").toString())
/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR
> console.log(child_process.execSync("tree -af").toString())
.
└── ./DT20230603_093430_074_4211____nv_cli_how_many_workers___
1 directory, 0 files
*/
//now listen on a unix-sock which created in this long dir:
var creat_srv = (idx=0)=> {
let usock = `___usock${idx}___`;
usock = path.join(WORKDIR,usock);
try { fs.unlinkSync(usock);} catch(err) {}
console.log("will listen on: ", usock)
const server = http.createServer((req, res) => {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end('okay');
});
server.listen(usock);
return(server);
}
var s0 = creat_srv(0)
// the server s0 will success:
/*
> s0._pipeName
'/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_094727_967_1235____nv_cli_how_many_workers___/___usock0___'
*/
//but:
console.log(child_process.execSync("tree -af").toString())
/*
.
├── ./DT20230603_093430_074_4211____nv_cli_how //#0======> 【wrong name sock-file created】
└── ./DT20230603_093430_074_4211____nv_cli_how_many_workers___
1 directory, 1 file
*/
// check the trimmed length of #0
/*
> "/mnt/sdb/NV5/NV5_/nvcli-/pkgs/PERF/nv-cli-how-many-workers/WORKDIR/DT20230603_093430_074_4211____nv_cli_how".length
107 -----------> 【107 is unix-sock max-szie on my linux】
*/
so in this secenario .
i think server.listen should 【THROW-a-error】 instead of 【let-the-creat-action-succeed】
What is the feature you are proposing to solve the problem?
http'server 'listen on unix_sock should throw-a-error IF the-input-sockname EXCEED the maximum linux-limit
What alternatives have you considered?
in testbed enviroment:
long path name is NOT rare (coz the normally generated by script)
when auto creat many many server listen on unix sock in a nested directory, long path name is possible
for example, in my test bed , i created 2400 http server on a machine( for test one route one instance)
dt : 2400 created CPU:176 MEM: 1380974592
usock DT20230603_104937_506_5224____nv_cli_how_many_workers___/usock2400
some server name is too long, but they be created successfully with the wrong-sock-name(trimed)
changed the title [-]http'server 'listen on unix_sock should throw a error IF the-input-sockname EXCEED the maximum linux-limit [/-][+]http'server 'listen on unix_sock should throw a error IF the-input-sockname-length EXCEED the maximum linux-limit [/+]on Jun 3, 2023
Libuv issue, continues in libuv/libuv#4036. I already made that change in a pull request that's close to getting merged, although that was somewhat by accident.
FWIW, this particular quirk is documented in the libuv documentation. As such, libuv can't really change it without breaking backwards compatibility. The upcoming uv_pipe_bind2() and uv_pipe_connect2() functions could add a flag that makes them return an error instead of truncating the path.
When libuv/libuv#4040 lands and node upgrades to libuv v1.46.0, node can decide to use the new flag. Reopen the issue (or better, a pull request) if you think it's a good idea to change the current behavior.
Activity
[-]http'server 'listen on unix_sock should throw a error IF the-input-sockname EXCEED the maximum linux-limit [/-][+]http'server 'listen on unix_sock should throw a error IF the-input-sockname-length EXCEED the maximum linux-limit [/+]bnoordhuis commentedon Jun 4, 2023
Libuv issue, continues in libuv/libuv#4036. I already made that change in a pull request that's close to getting merged, although that was somewhat by accident.
bnoordhuis commentedon Jun 4, 2023
FWIW, this particular quirk is documented in the libuv documentation. As such, libuv can't really change it without breaking backwards compatibility. The upcoming uv_pipe_bind2() and uv_pipe_connect2() functions could add a flag that makes them return an error instead of truncating the path.
bnoordhuis commentedon Jun 5, 2023
When libuv/libuv#4040 lands and node upgrades to libuv v1.46.0, node can decide to use the new flag. Reopen the issue (or better, a pull request) if you think it's a good idea to change the current behavior.