Hi Tim, You are right, it doesn't execute, but some subprocess (like a CGI) could try to execute.
This comment there shed some light about it: "I wouldn't describe O_CLOEXEC as there principally for privilege escalation / security reasons -- it's also very, very common to have non-security bugs happen (frequently of the indefinite-blocking variety) if a FD is left open beyond when it's intended to be closed because a subprocess still has it." So, why does removing SOCK_CLOEXEC make http work? If the fd is not executed, the socket shouldn't be closed, right? And why was it working in the past? Which modification broke this? Maybe understanding it is important to have the right fix (maybe removing it is acting as a band-aid). Wengzhe, could you please help us to understand this network issue? BR, Alan On Tue, Jul 1, 2025 at 12:28 PM Tim Hardisty <timhardist...@gmail.com> wrote: > But that's the point - thttp *does* call exec() so the open socket file > descriptor gets closed when it is still needed by the exec'd application. > > If there's another way of doing this I'm listening! > > On 01/07/2025 16:13, Alan C. Assis wrote: > > Hi Tim, > > > > Nice finding! > > > > Now we need to understand why this worked in the past and now it doesn't. > > > > Also, what are the implications of removing SOCK_CLOEXEC? A few pointers > > here: > > > https://stackoverflow.com/questions/22304631/what-is-the-purpose-to-set-sock-cloexec-flag-with-accept4-same-as-o-cloexec > > > > BR, > > > > Alan > > > > On Tue, Jul 1, 2025 at 11:27 AM Tim Hardisty <timhardist...@gmail.com> > > wrote: > > > >> The error was, indeed, the socket being opened with the SOCK_CLOEXEC > >> flasg set. > >> > >> PR to follow. > >> > >> On 28/06/2025 16:16, Tim Hardisty wrote: > >>> Actually - it might be a change last year. The socket is now opened > >>> like this and I assume CLOEXEC will mess up the operation of the > >>> executed CGI app (will investigate on Monday; not sure what socket > >>> mode it needs to be): > >>> > >>> hc->conn_fd = accept4(listen_fd, (struct sockaddr *)&sa, &sz, > >>> SOCK_CLOEXEC); > >>> > >>> On 28/06/2025 13:22, Alan C. Assis wrote: > >>>> Hi Tim, > >>>> > >>>> Yes, I think send() is the preferred form to work with sockets > >>>> because you > >>>> can have fine control, i.e. passing flags at forth argument > >>>> (MSG_DONTWAIT, > >>>> etc). > >>>> > >>>> If you suspect that the bug was caused by some recent modification, > >>>> try to > >>>> find a supported board that was used to test thttpd in the past and > >>>> test an > >>>> old NuttX release with it. > >>>> This is the approach I use to double check if something is broken in > the > >>>> mainline. > >>>> > >>>> BR, > >>>> > >>>> Alan > >>>> > >>>> On Fri, Jun 27, 2025 at 3:39 PM Tim Hardisty <timhardist...@gmail.com > > > >>>> wrote: > >>>> > >>>>> Is it as "simple" as thttpd should do: > >>>>> > >>>>> nwritten= send(sock_fd, buffer, totalbytesread, 0); > >>>>> > >>>>> rather than the generic: > >>>>> > >>>>> nwritten= write(sock_fd, buffer, nbytes); > >>>>> > >>>>> On 27/06/2025 18:40, Tim Hardisty wrote: > >>>>>> Trying to get thttpd's CGI handling working and have found that the > >>>>>> dup(2) calls of stdin and stdout return a file descriptor that's > >>>>>> already been allocated to the NET socket (via thttpd I think). > >>>>>> > >>>>>> That isn't right is it? > >>>>>> > >>>>>> I am not sure if it's a side effect of something that thttpd does > >>>>>> (that might have been OK in the past but is now not right) or a > NuttX > >>>>>> bug, of a missing Kconfig setting that relates to this. > >>>>>> > >>>>>> The result is that the ultimate copying of buffered html that should > >>>>>> be written via the socket FD gets rejected as the FD doesn't have WR > >>>>>> access (and is now the wrong FD anyway!). > >>>>>> > >>>>>> Perhaps there's been a change in the way NuttX deals with all of > this > >>>>>> that didn't get sorted in thttpd? > >>>>>> >
