Open dansteen opened 8 years ago
Interesting. Maybe an acbuild ln
command would be an acceptable solution to this?
Also just so I understand the use case better, why does your application need these files to exist?
hi @dgonyeo,
Thanks for the reply! The application writes messages out to /dev/stdout
and /dev/stderr
(stdin above was just by way of example), under the assumption that these links exist in most distros, and when running under systemd this is the "correct" way to do things. I've reached out to the developer to see if I could get things adjusted, but this seemed like a valid general case issue, so I figured I'd open a ticket.
There is a lot of discussion of this sort of issue in the docker world (here as an example: https://github.com/docker/docker/issues/8755)
Thanks!
Now that I've thought of it I would like to create an acbuild ln
command (it would be generally useful), but maybe a rkt flag to generate these at runtime would also be appropriate. I'll file an issue over in the rkt repo for at least consideration.
And crosslinking this: https://github.com/coreos/rkt/issues/3294
The acbuild ln
command should be a separate issue, to keep things clear. Once coreos/rkt#3294 is resolved, this can be closed, I think.
When building container images with acbuild. acbuild automatically creates /dev/std* in the container for each
acbuild run
command:However, rkt does not create these links in the running container:
This creates issues actually adding in those links for applications that need it:
Even worse, If you force it with
-f
, acbuild will remove the link you create (I assume under the assumption that it created it).In the end I wound up using COPY:
But it took some time to figure out that I could do that, and was quite confusing. This becomes even more of a problem if you need to create a link that does not exist in your current system (something like
/dev/console
to/dev/std(in|out)
for systemd). Then you have to keep a copy of the link you need in your repo and copy that in.Thanks!