Can i redirect a detached containers stdout and stderr?

[towe75]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

I'd like to redirect a detached containers stdout/stderr to a file/socket.

Additional information you deem important (e.g. issue happens only occasionally):

This is a issue i found while working on nomad-driver-podman.

Nomad provides some nice integration for the two streams, it's enough to just redirect the content into a precreated socket. As a POC i simply redirected podmans logger output and it works. The drawback is, however, that i can not distinguish between regular output and error messages.

So i wondered how to solve this in a better way:

1. i could use varlink attach and stream the content into nomads sockets
2. implement an alternative logger which can write two log streams/files instead of just one
3. more efficient: maybe conmon can redirect the streams directly?

Regarding 3, i found this in conmon sources:

https://github.com/containers/libpod/blob/3e2d9f8662663f2f703bf674408d5255e493e18e/libpod/oci_conmon_linux.go#L933

        // TODO this is probably a really bad idea for some uses
	// Make this configurable
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr

[mheon]

We're doing some unrelated work on the attach API endpoint that might make this easier, but no exact ETA on that yet.

[towe75]

Hey @mheon, thanks for checking.
There is no real presure, so i'll wait for the attach API change.

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[onlyjob]

@github-actions is in denial of all valid issues, adding noise everywhere... :(

[rhatdan]

I disagree, this is waking us up to old issues, that get buried on the stack. When these happen primary contributors go back and review the issue and either allow it to be closed, or remove the stale flag.
I think this is better then just letting issues rot.

[onlyjob]

I've seen it far too many times when such practice causes closure of legitimate issues because team member did not respond. People quickly learn that not answering tickets and letting them expire takes least effort.
Auto-closure is a terrible practice for issue management and it is incredibly frustrating to reporters.
You see, when I care to report a problem and it can not be fixed because developers are busy or have greater priorities, it is fair, it is understandable. Reported issue then becomes a point of communication between others who is affected by it and you never know who might eventually contribute a patch.
But when the issue is closed without an action, that's denial, discouragement. A slap in the face of reporter and others who cares. A strong feedback saying "your issues are not important to us" which is not too different from private issue trackers.
An issue is an issue and the problem does not go away from closing the ticket because the real problem is prioritising. Just never ever (auto-)close actionable tickets without doing anything.

[vrothberg]

I think @onlyjob is right. We don't want to scare off contributors. The intention of closure was more to get the developers' immediate attention. I'll bump the limit to 356 days and rephrase the wording.

[rhatdan]

On the other hand, leaving a issue to wither on the vine, because of lack of resources or lack of priority, is not much better. Some times kicking the issue, is helpful to see if the reporter is still seeing the issue, or if the issue is even still important.

Just today, I closed two issues, that were >30 days and fixed in Master.

[baude]

@vrothberg please bring up during scrum next week before making a change.

[vrothberg]

I opened #4788 before reading the comment

[baude]

@mheon fixed? @towe75 have you been able to try master?

[mheon]

I think that APIv2 should remove the need for this

…

On Mon, Jan 27, 2020, 15:53 Brent Baude ***@***.***> wrote: @mheon <https://github.com/mheon> fixed? @towe75 <https://github.com/towe75> have you been able to try master? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4560>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCCZIW4A23E6UWTVKRLQ75CWHANCNFSM4JQ2XVXA> .

[towe75]

@mheon I was not aware about your ApiV2 branch until now, so i did not try it yet. I like the idea of not depending on varlink.

But my question was actually about telling podman to redirect the streams to a different file or socket, regardless of the used api transport/encoding.

I assume that the new API can poll/stream both streams to a client. This would help me to do a proper integration, although it's not the most elegant way.

[rhatdan]

Since we are not updating varlink, closing this issue.