On Sat, Dec 27, 2025 at 1:16 PM 'TheDiveO' via golang-nuts <[email protected]> wrote: > > I want to start a new child process in a new PID namespace. Looking at > syscall.SysProcAttr there are both "Cloneflags" and "Unshareflags". Beyond > the obviously less friendly and not really helpful answer "because there's > clone(2) and unshare(2)", what is the reason for not being able to go with > just the Cloneflags, especially when it comes to unsharing (sic!) namespaces > as part of clone(2)? > > Initially, I used Unshareflags with unix.CLONE_NEWPID and this caused "weird" > behavior when the child process happened to be a Go binary: runtime/cgo not > being able to create a pthread and then some other part of the runtime > spilling its guts including CPU registers, or alternatively a similar cannot > create new thread (errno? = 22) and also CPU register guts. > > Only after some time I realized I might try to move unix.CLONE_NEWPID to > Cloneflags instead ... and instant success. While I have a working solution, > I would like to understand the rationale(s) between doing "some" things > (which?) better not in clone(2), but in the child's unshare(2) before > replacing the child copy with the intended binary?
If you set Unshareflags then the child process will call unshare with those flags. If Unshareflags is left as zero then the child process will not call unshare. The parent process will always call clone (or clone3), and it will pass Cloneflags when it does. Perhaps everything that can be done with Unshareflags can be done with Cloneflags. It's possible that it was a mistake to add Unshareflags. 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU-Jpq_7S%3DrV3zqgU%2BP1a13wU-3ibMpPJoi9LM%2BHUkmCw%40mail.gmail.com.
