keep init service execs connected to docker logs

[gdraheim]

When doing a "docker run" then "docker logs" will show the output of the process in the container. The systemctl replacement however will divert all output into some /var/log area and one has to use additional tools to get to the output (it would be journalctl for a real systemd).

When the systemctl docker replacement is running as the init process then it may be possible to keep the output channels of the started commands connected to the standard out/err of the script. That would allow access the results with "docker logs". May be one can dup() the channels to have both, but may be some forking services can not stay connected.

[gdraheim]

Thinking about it:

may be it is a good idea to leave the output redirection as it is. They are now put into a seperate log file so that one ask for the log of each service seperately.

When running as an init-process one can do another trick instead - by creating a thread that watches the log files of the started services, so that their lines are re-printed to the init-process output channel. In addition to just re-printing one can also add a prefix as to which service it was. That allows easily have multiple services run in one container while still following the docker idea of one service per container.

[gdraheim]

instead of doing a thread, the init-loop does it itself - we are going to open the log-files of all known services in a read-mode. In each tick of the zombie reaper (every 5 seconds) the logs are read, and every full line (ending in a newline) is printed, while buffering the remaing parts.

That makes it effectivly look so that "docker logs" prints the output of all services in the container. In addition to a single-service container the init-loop output does prefix each line with the service name, so that you get:

INFO:TESTING:------- docker logs

zzb.service: starting B
zzb.service:
zzc.service: starting C
zzc.service:

The functionality is backed by testcases
make test_3700
make test_5120