I used to echo something to /proc/1/fd/1 in order to see that something to show up in the log.
And this works even now, but… have you got any best practice to doing the same while using the old INITSYSTEM?
The side effect seems to be chat echoing something to /proc/1/fd/1 does not work anymore, since that file descriptor seems to be linked to /dev/null within /proc.
If you do an echo from a script application launched by the container, the message should appear in the logs. Isn’t this the case?
I can’t really see the point of doing an echo from the command line in a container and that message to show up in the logs window. Can you let us know why you would want this functionality?
I imagine you’re trying to have several programs / services send stuff to the logs outside of the container’s CMD? I’ve tried using /dev/console for that and it seems to work, e.g.
echo foobar > /dev/console
Will output “foobar” to the container’s TTY output, and therefore to the dashboard logs. But this can break in some scenarios (e.g. if you mount a devtmpfs in /dev, which some base images used to do), so whether or not it works depends on your image.
@spanceac, @pcarranzav, I can share a sample Dockerfile, if you like.
As you already know, every script/program run via CMD would actually send its output to log.
As you can see there, job.sh is using " echo job >/proc/1/fd/1" to output to log, because job.sh is run via cron, while start.sh does not need “>/proc/1/fd/1” just, because it is run via CMD. Now that the INITSYSTEM has been removed, as long as you bring it back into action as shown on https://www.balena.io/docs/reference/base-images/base-images/#installing-your-own-initsystem the job.sh would not output to log anymore! It seems that “>/proc/15/fd/1” works. But I don’t know if I can rely on this.
