exec.Command run in background

[brad.rydzewski]

I'm trying to execute a command in Go
cmd := exec.Command(name, args...)
out, err := cmd.CombinedOutput()

I can execute most commands fine, but I need to execute a command that
runs in the background as a daemon

When I execute the command I get this error:
ERROR inherited fd 6 on anon_inode:[eventpoll]

I can execute from the command line and it works fine. I've tried to
execute the command from a shell script via Go, and I get the same
error. I'm looking through the code for answers, but was hoping that
perhaps someone in this group could offer suggestions

Thanks

[Dave Cheney]

Hello,

This doesn't look like a problem with exec package per se, however it
could be that a file descriptor from your Go program is leaking into
the child.

What is the program you are exec'ing ?

Cheers

Dave

[Ian Lance Taylor]

"brad.rydzewski" <brad.ry...@gmail.com> writes:

You didn't mention the OS you are using, but I'm going to guess that it
is GNU/Linux. I think the problem is that we are not marking the epoll
descriptor as CLOEXEC. Can you try
http://codereview.appspot.com/5494061 to see if it fixes your problem?

Ian

[brad.rydzewski]

Ian,
Thanks for putting together a patch so quickly. I did quite a bit of
testing, and it absolutely solved the problem.
Any chance I will see this in the weekly tag any time soon? Thanks!

On Dec 16, 7:40 pm, Ian Lance Taylor <i...@google.com> wrote:

> descriptor as CLOEXEC.  Can you tryhttp://codereview.appspot.com/5494061to see if it fixes your problem?
>
> Ian

[Brad Fitzpatrick]

I'd like to understand why this bit you and it's never bit any other code that uses exec.  (at least, it's never bit me, and I've used exec for background stuff a fair bit)

Do you have a minimal case that fails?  This patch shouldn't go in without such a test in any case.

[Ian Lance Taylor]

Brad Fitzpatrick <brad...@golang.org> writes:

> I'd like to understand why this bit you and it's never bit any other code
> that uses exec. (at least, it's never bit me, and I've used exec for
> background stuff a fair bit)
>
> Do you have a minimal case that fails? This patch shouldn't go in without
> such a test in any case.

There is only going to be a problem when using the net package and
simultaneously using exec to run a command that checks for open file
descriptors other than 0, 1, and 2. That is not the common case; most
programs don't care if they are invoked with additional open file
descriptors.

Ian

[Rob 'Commander' Pike]

On Dec 18, 2011, at 11:12 PM, Ian Lance Taylor wrote:

> Brad Fitzpatrick <brad...@golang.org> writes:
>
>> I'd like to understand why this bit you and it's never bit any other code
>> that uses exec. (at least, it's never bit me, and I've used exec for
>> background stuff a fair bit)
>>
>> Do you have a minimal case that fails? This patch shouldn't go in without
>> such a test in any case.
>
> There is only going to be a problem when using the net package and
> simultaneously using exec to run a command that checks for open file
> descriptors other than 0, 1, and 2. That is not the common case; most
> programs don't care if they are invoked with additional open file
> descriptors.

Perhaps the programs don't care, but I do. It's a nasty security hole. Off-topic but important.

-rob

[Russ Cox]

The easiest way to test this would be to exec a program
and then open 100 files in a row and make sure you get
3-102.

Russ

[Brad Fitzpatrick]

Yup, just sent out http://codereview.appspot.com/5490075

It fails currently.

[Ian Lance Taylor]

Oh, sure, needs to be fixed, I'm just explaining why most people don't
notice this.

Ian