Re: Following log directories

[Carl Winbäck]

On Thu, 25 Jun 2020 at 17:00, Guillermo wrote:
> And it appears to be compatible, indeed, as long as s6-log is invoked
> with the 't' directive (prepend timestamp in TAI64N format), to match
> the logging file format expected by follow-log-directories, as stated
> in its documentation.

Neat! Thank you Guillermo for this information.

Best regards,
Carl

Following log directories

[Carl Winbäck]

Hi folks!

Does anyone know if the follow-log-directories tool[1] from the nosh
suite is compatible with logs produced by s6-log?


Best regards,
Carl Winbäck a.k.a. cpach



[1] https://jdebp.eu/Softwares/nosh/guide/commands/follow-log-directories.xml

Re: Logging in a web server context

[Carl Winbäck]

On Sat, 13 Jun 2020 at 14:53, Laurent Bercot wrote:
>   I'm generally not a fan of fan-in fan-out mechanisms (pun unintended),
> because it's a lot easier to mix data than to triage it, so if data
> streams are separated early, mixing them to transmit them over one
> channel then parsing the data to separate it into several streams again
> is wasteful. Having the ability to keep service-specific log stream
> rather than conflating everything into a global logger is one of the
> big advantages of the s6 logging infrastructure over the syslog model.

I agree with your reservations. But as you concluded, given the
currently available tools the “mix and split” method is a reasonable
trade-off for this use case.

Re: Logging in a web server context

[Carl Winbäck]

Thank you Laurent, for taking your time to express your views
regarding this class of daemons.

On Sat, 13 Jun 2020 at 14:43, Laurent Bercot
 wrote:
> The nginx/apache case is something that comes up with some
> regularity, either on this list or on the #s6 channel, so I should
> try and write some tools that make it easier to automate.

Cool. Such tools could be very useful.

> However, it is likely that those tools would become part of s6-rc,
> not s6, because doing things in a reliable way involves a fdholder,
> which requires some policy that s6 does not provide but s6-rc does
> (and s6-rc already has all the necessary infrastructure).

Makes sense. AFAICT any heavy user of s6 would anyway need s6-rc or an
equivalent.

Re: Logging in a web server context

[Carl Winbäck]

On Sat, 13 Jun 2020 at 13:59, Casper Ti. Vector  wrote:
> > I gather from it that what I want is currently not possible without
> > s6-rc. Is that correct?
>
> I do not think so :)  In a nutshell, your service needs to connect its
> stdout and stderr to a pair of different loggers; that can be done by
> fd-holding and chainloading, and is how s6-rc internally implements its
> piping (well, funneling) mechanism.  However, s6-rc only connects the
> stdout, so the fd-holder needs an amount of additional configuration
> whether you use s6-rc or not; that amount will be a bit big without
> s6-rc, but it is surely doable and even scriptable.

Aha! Implementing such a mechanism (outside of s6-rc) could be an
interesting exercise.

However, I believe that the proposals Jan posted would be sufficient
for my needs.

Re: Logging in a web server context

[Carl Winbäck]

On Sat, 13 Jun 2020 at 14:17, Carl Winbäck  wrote:
>> Replying to a private mail here on the list in case it is of interest
>> to someone else.[1]

Sorry for the botched quote level. I should know better than to use
Gmail’s web interface for posting to mailing lists :-p

Re: Logging in a web server context

[Carl Winbäck]

>
> Replying to a private mail here on the list in case it is of interest
> to someone else.[1]
>
> On Sat, 13 Jun 2020 at 12:05, Arsen Arsenović  wrote:
> > You're interested in nginxes `error_log', `access_log' and
> > `log_format' directives, I believe.
> > It can write both directly to a file, for better or for worse.
> > You could use fifos to separate the logs into different logdirs, but
> > I'm unsure of how well that would work, since AFAIK it also tries to
> > rotate logs every so often.
>
> Yes, nginx can write its messages to either stdout, stderr, syslog or
> directly to a file. Nginx itself will not do any log rotation. That
> could be handled by logrotate(8). But IMHO, using logrotate(8) or
> syslog feels like clumsy and outdated solutions.
>
> Syslog was introduced in the early 80s and I don’t believe that its
> design has aged well. logrotate(8) has the issue that it cannot work
> in tandem with neither the daemon nor the supervisor. This is
> something that Jonathan de Boyne Pollard has described well in his
> article “Don’t use logrotate or newsyslog in this century”.[1]
>
> > Personally, I'd just drop access logs entirely in favor of either
> > nothing, or Matomo.
>
> Yes, that could be an option and I will consider it. It needs way more
> computing resources though[3]. With that said, this option offers some
> features that an access log analyzer doesn’t.
>
>
>
> [1] Arsen has approved of this posting :)
> [2] https://jdebp.eu/FGA/do-not-use-logrotate.html
> [3] See
> https://www.mail-archive.com/supervision@list.skarnet.org/msg02185.html
> [4]
> https://matomo.org/docs/requirements/#recommended-servers-sizing-cpu-ram-disks
>

Re: Logging in a web server context

[Carl Winbäck]

On Sat, 13 Jun 2020 at 12:59, Jan Braun  wrote:
> I'm not completely sure about s6, but runsv (from runit) hands only the
> stdout of the ./run script to the logger, and passes the stderr out of
> it's own stderr. This allows you to nest two runsv instances, one for
> each output channel:
>
> [...]
>
> Translation to s6 is left as an exercise to the reader.

Very interesting! I will study this example in depth in order to see
if it could be applied to s6.

If anyone has done this in s6, I would be interested to hear how you
achieved it.

> You could also run the webserver with stderr redirected to stdout, and
> let s6-log/svlogd filter the messages into one of two logdirs:
>
> $ printf 'stdout\nstderr\n' | s6-log -- '-.*err' t ./stdout f t ./stderr
> $ head std*/current
> ==> stderr/current <==
> @40005ee4acd00efdfbe9 stderr
>
> ==> stdout/current <==
> @40005ee4acd00efd6f5e stdout
>
> However, that's a brittle solution, because it relies on you creating
> correctly-matching filter rules. Depending on the webserver's output, it
> might still be feasible, but I recommend the other approach.

I agree that this method is not rock-solid since it relies on text
parsing. But for my purposes it would probably be sufficient.

Then I have at least one solution that should be feasible and possibly
both of them are.

Thank you Jan!

Re: Logging in a web server context

[Carl Winbäck]

On Sat, 13 Jun 2020 at 12:04, Casper Ti. Vector  wrote:
> See ?

If you like, feel free to expand on the previous discussion.[1]

I gather from it that what I want is currently not possible without
s6-rc. Is that correct?



[1] Trying to browse the old archives was a bit confusing, it seems
like the threading was a bit weird.

Logging in a web server context

[Carl Winbäck]

Hi folks!

Is it possible when using s6-svscan/s6-supervise to somehow arrange so
that a daemon’s stdout is sent to one logdir and stderr to another
logdir?

Or must I use s6-rc in order to achieve this?

My premises are the following:

I want to run nginx under s6, on a mainstream Linux distro such as
Debian/Ubuntu/CentOS. My plan is currently to use s6 only for nginx
and not any other daemons.

I want to collect the web server access logs in order to generate
visitor statistics[1].

One tricky aspect of logging that is specific to web servers is that
they emit two different categories of messages:

a) Errors and warnings

b) Info about page requests[2]

For many other kinds of daemons, one only needs to arrange for logging
stderr and then call it a day. With web servers it’s not quite so
simple.

I am very interested to hear from others on the list what your
thoughts are about this scenario.

The reason I’m weary about s6-rc is that I think it might not play so
well with the distros I mentioned earlier. If this concern is not
correct, please let me know.



[1] An alternative to collecting access logs could be to use Google
Analytics instead, but I want to avoid that since I don’t feel
comfortable about handing over my visitors’ personal data over to
Google.

[2] I.e. lines like this '10.131.214.101 - - [20/Nov/2017:18:52:17
+] "GET / HTTP/1.1" 401 188 "-" "Mozilla/5.0 (X11; Ubuntu; Linux
x86_64; rv:47.0) Gecko/20100101 Firefox/47.0"'

Re: Mailing list archives?

[Carl Winbäck]

On Sat, 28 Dec 2019 at 12:02, Casper Ti. Vector  wrote:
> See ?

Thank you Casper!

Mailing list archives?

[Carl Winbäck]

Hi folks!

Are there any archives of the supervision list available online?

The links over at http://smarden.org/runit/ are unfortunately
broken. (http://skarnet.org/lists/archive.cgi?2
resp. http://news.gmane.org/gmane.comp.sysutils.supervision.general)


Best regards,
Carl