Adding option to specify user / uid&gid for logutil-service about s6-overlay

[glerchundi]

@robinroestenburg can you give me an use case in which this would be useful? Not providing uid/gid was an intended behaviour because s6-log already outputs everything with 0644 mode and anyone could read logs.

Taking advantage of the occasion, did you find these utilities useful? I have mixed feelings related to logging...

[robinroestenburg]

@glerchundi hmm, I overlooked that. Is that a feature of the s6-log program?

The log directories on my images are volumes that are linked from the docker host. My s6-images log using a user that I know is present on the host. I was converting the log scripts to use logutil-service and wanted to keep the uid the same to avoid problems.

But I guess 0644 will do the trick.. I am in the process of logging every to a separate data container (for processing with logstash), it won't even matter after that.

Taking advantage of the occasion, did you find these utilities useful? I have mixed feelings related to logging...

The images inheriting from my s6 base image now have 12 logging fifos configured. They all had the same setup and logging scripts. So, this reduces a lot of duplication and is more readable.

On the other hand, the scripts were not too complex and there is no magic for new users / other colleagues to figure out. But I think that does not outweigh the previous points..

What are your doubts?

[glerchundi]

Yep, it's interesting to see how do people handle logging in containerized world. I thought exactly the same thing as you did. Log different kind of errors to different places (nginx: error, access | mariadb: error, general-query, slow-query) and then forward to a centralized place (using fluentd, logstash or whatever) but not before tagging them.

The images inheriting from my s6 base image now have 12 logging fifos configured. They all had the same setup and logging scripts. So, this reduces a lot of duplication and is more readable.

Wow, so definitely this helps keeping everything as DRY as possible.

On the other hand, the scripts were not too complex and there is no magic for new users / other colleagues to figure out. But I think that does not outweigh the previous points..

That was my concern, if this would be interesting just for me because i'm not aligned with the people thoughts or not. And if these scripts hide details that would make things happen automagically.

What are your doubts?

Doubts solved. Thanks for your feedback!

[dreamcat4]

In general terms of logging, (not specific to s6) i am looking forward to the rotation support, they will officially add in next versions of docker.

Actually I try to rotate my logs now with logrotate, but it doesn't actually rotate them.

[glerchundi]

@dreamcat4 in the latest release (1.10.0.3) log rotation comes out-of-the-box with this configuration (which can be override by using S6_LOGGING_SCRIPT envar):

n20 s1000000 T configuration in s6-log means (as "stated" by s6-log documentation): "Logs all of stdin, prepending every line with a ISO8601 timestamp, with a maximum archive of 20 log files of 1 MB each"