Filed under https://github.com/golang/go/issues/58369.
-- Lucas Christian Staff Software Engineer, Voice and SIP Connectivity On Fri, Feb 3, 2023 at 2:14 PM Ian Lance Taylor <i...@golang.org> wrote: > On Fri, Feb 3, 2023 at 1:48 PM Lucas Christian <lchrist...@twilio.com> > wrote: > > > > Thanks for the reply and confirmation—theoretical but we have had > systems fail this way before (including the system this codebase will > eventually be deployed on). Of course practically once that happens, the go > process leaking one more file descriptor is probably the least of our > worries. > > > > For completeness is there an issue tracker it would be worth filing this > off to? > > > https://urldefense.com/v3/__https://go.dev/issue__;!!NCc8flgU!aclVyNiB3jXq50nLgI3WT74VmhVQaslq5Q_idqxqQ3QGe2HY-8Bx2A1dkZvNyGTYBD6wvTQF3tG0ng$ > (which redirects to GitHub). > > Ian > > > > Lucas Christian > > Staff Software Engineer, Voice and SIP Connectivity > > On Fri, Feb 3, 2023 at 12:44 PM Ian Lance Taylor <i...@golang.org> > wrote: > >> > >> On Fri, Feb 3, 2023 at 12:38 PM 'Lucas Christian' via golang-nuts > >> <golang-nuts@googlegroups.com> wrote: > >> > > >> > Apologies for reviving an old thread, but thought this might be the > most efficient way to keep context. > >> > > >> > I'm looking at a similar issue Thomas encountered, but in this case > I'm concerned about how to handle errors returned from > StdoutPipe()/StderrPipe() and properly clean up after that. e.g.: > >> > > >> > cmd := exec.Command(myCommand, myArgs...) > >> > > >> > stdout, err := cmd.StdoutPipe() > >> > if err != nil { > >> > // log warning or bail out > >> > } > >> > > >> > stderr, err := cmd.StderrPipe() > >> > if err != nil { > >> > // log warning, if we bail out we will leak the os.Pipe > allocated internally in cmd.StdoutPipe() > >> > } > >> > > >> > err = cmd.Start() // if this fails, it *will* clean up both pipes > >> > > >> > Looking at the source, both StdoutPipe() and StderrPipe() allocate > os.Pipe()s internally. Since these methods return the reader I can > technically close that one myself but the writer side of the pipe will > presumably leak if cmd.Start() is never called. In my usecase it's probably > an acceptable compromise to just complain to the log and move along with > starting the process, but if my understanding is correct it feels like an > omission in the language spec that there is seemingly no way to clean up a > the pipes associated with a command that is never started. > >> > >> As a practical matter I wouldn't worry about it, as StdoutPipe and > >> StderrPipe should approximately never fail. I think that the only way > >> they could fail would be if you hit the limit on the total number of > >> open file descriptors. > >> > >> If they do manage to fail, it's a fair point that there is no > >> supported way to close any earlier pipes. Again it's unlikely to be a > >> practical problem as any lingering file descriptors will get closed by > >> the finalizer associated with each file descriptor. But, yes, it > >> looks like a bit of a hole in the API. > >> > >> Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHTUVAgpMhoMt4x9z-zRiC1P2mqx_WQguWs8nT6XQ0V86ED9Gw%40mail.gmail.com.
