Allow retrieving stdout/stderr from a backgrounded exec

[stgraber]

When spawning exec without websocket, it'd be nice to have an extra flag in the API which would have the server capture stdout and stderr and make them available through the operation entry.

[srkunze]

What exactly does this mean?

[tych0]

On Wed, Dec 09, 2015 at 02:26:09PM -0800, Sven R. Kunze wrote:

What exactly does this mean?

we don't capture stdout/stderr by default since they could be very
large and the user may never request them. the idea with this flag is
for users to be able to capture them to be stored for later
acquisition.

I think we initially filed this when we kept operations around
forever. Now that we delete them, it may not even make sense to have
this; if you want to interact with the command, you should probably
just use interactive mode.

---

Reply to this email directly or view it on GitHub:
lxc/incus#180 (comment)

[stgraber]

Yeah, if we wanted to still be able to retrieve them, we'd need to have an API under the operation to fetch them and then keep the operation in running state until after they've been fetched and the operation cancelled.

[srkunze]

You mean something for nohup lxc exec test -- ping localhost > log 2>&1 & but different?

[tych0]

On Wed, Dec 09, 2015 at 02:54:49PM -0800, Sven R. Kunze wrote:

You mean something for nohup lxc exec test -- ping localhost > log 2>&1 & but different?

i don't know what you mean by "but different" here, but yes. something
to capture the output from commands that are run in non-interactive
mode.

---

Reply to this email directly or view it on GitHub:
lxc/incus#180 (comment)

[stgraber]

This bug is about the LXD API rather than the client.

There is a feature in our API which the client doesn't expose that allows you to spawn a command inside the container and not attach to it, in that mode, the command will just run to completion and the background operation will return.

It's in that mode that we've been considering adding a way to keep the operation around and expose the content of stdout and stderr as it was when the command completed.

[srkunze]

There is a feature in our API which the client doesn't expose that allows you to spawn a command inside the container and not attach to it, in that mode, the command will just run to completion and the background operation will return.

I didn't know that.

However, it sounds extremely useful for automation and to get rid of that weird shell-specific file redirection syntax. (I daresay built-in logrotate-like functionality would be great here, too. ;) )

Te me, non-interactive stdout and stderr are basically log data only. So, you basically want something like a tee cmd to peek into the current stream of log data, right?

[stgraber]

Going to take a stab at this. One of my concerns when first thinking through this was polluting the host with all that console output. Luckily, we've since grown a log expiry mechanism that we can use for this.

Current plan is:

• Redirect stdout and stderr (independently) to two temp files inside the log directory of the container
• In the operation metadata, include the relative URLs to those log files

That will then allow the client to retrieve stdout and stderr for the next 48 hours, after which, the log expiry mechanism will kick in and clear those files.