Communicate process kill signals without being blocked by stdout/err reads

[0div]

Description

• use go channels to communicate signals to the handler read loops in envd and broadcast shutdown w/o being blocked by blocked reads
• make local envd more similar to what provision.sh does in template-manager

Test

I will commit an integration test in E2B js-sdk that goes like this:

test.skipIf(!isIntegrationTest)(
  'kill running nextjs app and make sure process is gone',
  async () => {
    const sandbox = await Sandbox.create(integrationTestTemplate, {
      timeoutMs: 120_000,
    })
    // const sandbox = await Sandbox.connect('inbpexoncdnuj9qld3pms-cf3f5359')

    const cmd = await sandbox.commands.run('cd /test-app && next dev', {
      background: true,
    })

    await wait(30_000)

    const pid = cmd.pid
    console.log('PID', pid)

    await sandbox.commands.kill(pid)
    await wait(10_000)

    const processes = await sandbox.commands.list()
    console.log('processes:', processes)
    assert.equal(processes.length, 0)
  }
)

[linear]

E2B-1790 Killing command by PID may not work as expected

[r33drichards]

chmod 777 seems excessive, but i'm low context, you might be better of with chown -R user /home/user and chown -R user /user/local

[0div]

I'm just mirroring what is done in provision script used in template manager, doesn't invalidate your comment tho—here's it's solely for local dev, however in template manager it's used for templates

[dobrac]

await sandbox.commands.kill(pid)
await wait(10_000)

is it necessary to wait after the kill? Shouldn’t the await be enough?

[mlejva]

await sandbox.commands.kill(pid)
await wait(10_000)

Agree with @dobrac here. Why to have wait here if we're already await kill?