Hi! I’m using /proc/1/fd/1 in Docker to redirect some file based logs to the standard output to avoid sh and tail etc. Is there maybe a similarly simple solution in a fly VM too because it doesn’t seem to work… thx.
In a Fly virtual machine, PID 1 is not the process spawned by your CMD. It’s our custom init program that manages a few things.
You should be able to use /dev/stdout and /dev/stderr respectively though.
If not, maybe /proc/self/fd/1? I’m not sure.
Actually none of those work, I tried them all.
I’m not entirely sure I understand what you’re trying to do 
Would you mind sharing some of these scripts? stdout and stderr should just work, including redirections. I think I might be able to help if I have a more concrete example.
Sure, I was expecting echo "Hello" > /dev/console to produce a log entry in fly logs.
I would like to use it in a container created from scratch image where an app expects a file as -logfile xxx parameter to log into. Passing -logfile /proc/1/fd/1 works, also -logfile /dev/console works with docker run but not with fly logs after deployment. I understand the PID 1 is a custom init code in fly. Is logging into /dev/console expected to work with fly?
It should work yes. I just tried it from my vscode remote (ssh) app:
$ sudo su -
# echo "Hello" > /dev/console
2021-01-02T11:39:44.984Z c77b8f67 ewr [info] Hello
You do need root permissions to write to /dev/console.
Our virtual machines are configured with a serial tty, so you can also write to /dev/ttyS0 (but you still need root access).
Your main’s program’s (<ENTRYPOINT> <CMD>) stdout and stderr are inherited from the parent process (PID 1, our init). If your app sends its logs to /dev/stdout and such, it should just work.
Thanks, I think it will be then a permission issue on my side: I cannot let the app run as root.
Thanks @jerome, if I give root permission the app can indeed log into /dev/console in the fly VM as well.
I expect you should be fine if the stdout redirect chain is not broken. If you provide your full dockerfile, entrypoint and everything relevant, I’m sure we can make it work without root!
We do not encourage the use of the root user.
Not so critical for me now but would be safer without root, we agree on that.
I appreciate if you find a solution to use this image without root. Thanks!
I think I found a bug in our init, preventing access to the ultimate destination of /dev/stdout for spawned processes.
Will update here once I’ve fixed it.
1 Like
@jveres I’ve pushed out a fix.
Essentially, /dev/stdout pointed at /proc/self/fd/1 which itself pointed at /dev/console which requires root to read/write from/to (as we’ve established before).
I switched that up to launch the child process with a pipe for both stdout and stderr. I also chowned the pipe’s file descriptor to the proper uid and gid (specified from the docker image, or else root).
Unfortunately, althttpd still won’t log there in my tests. I’m using your initial commit which doesn’t require superuser permissions. I’ve tested that it works by adding an ENTRYPOINT which echoed to the /dev/stdout pipe: without my fix, this didn’t work (permission denied).
So I’m thinking this could now be a bug in althttpd and symlinks? I tried running it with -logfile /dev/stdout and -logfile /proc/self/fd/1 and it did not work, even from docker (it didn’t log anything when making a request to it). How did you get it running with docker? Does it not log requests? What request are you issuing it to test this?
Hope this helps! Feel free to re-deploy to try it out.
althttpd is capable of running from xinetd and sends its output to the standard output.
Using -logfile /dev/stderr works with non-privileged user now, thanks a lot @jerome