supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: "Dewayne Geraghty" <dewayne.geraghty@heuristicsystems.com.au>,
	supervision@list.skarnet.org
Subject: Re: s6-log problem with +regex
Date: Fri, 10 May 2019 14:23:01 +0000	[thread overview]
Message-ID: <emcf4a5bbd-94bf-4f58-96d5-ea422a73b8ce@elzian> (raw)
In-Reply-To: <a6b68a3a-4da2-e1e7-a874-b41b52d6fea7@heuristicsystems.com.au>


>However without any control directive, the result is:
>s6-log: usage: s6-log [ -d notif ] [ -q | -v ] [ -b ] [ -p ] [ -t ] [ -e
>] [ -l linelimit ] logging_script
>
>Though running s6-log without a control directive is probably a little
>silly, perhaps the requirement to have one may be worthwhile mentioning
>in the doc.

  Again, I cannot reproduce that, either on Linux or on FreeBSD.
Running s6-log without a control directive works as intended for me.
Can you please paste the exact command line you're running that causes
the issue for you ?


>Aside: I had orginally placed
>ErrorLog "|/usr/local/bin/s6-log -b n32 s50000 S7000000
>/var/log/httpd-error T !'/usr/bin/xz -7q' /var/log/httpd-error"
>into apache24 which worked well in testing (one httpd), but of course in
>production there are lots of httpd that do NOT use the parent for
>logging errors, so locking is a problem.

Locking won't be a problem unless your services are logging lines
that are longer than (at least) 4 kB. For lines that are shorter than
4 kB, writing/reading a line through a pipe will be done atomically.
In a normal Apache logging configuration, lines won't be too long,
so you'll be fine.


>Because I have three websites (3x error files, 3x access files) I was
>looking at using 6 pipelines into two s6-log processes and regex's to
>route the content. (hence my original example).  Is this a good use of
>resources or better to pipeline (funnel) to their own s6-log?

  It's entirely your choice. The s6-log process doesn't take a lot of
resources on its own, so my default choice would be to use a s6-log
process per log stream - because it's always easier to merge logs
than it is to separate them. If your priority is to use the least
amount of CPU, or if you're not sure, definitely use more s6-log
processes and less regex matching. But if your priority is to use as
little RAM as possible, you'll probably get slightly better results
by funneling several log streams into one s6-log process and using
some regex matching. I have not profiled this, though.

--
  Laurent



      reply	other threads:[~2019-05-10 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10  1:02 Dewayne Geraghty
2019-05-10  2:27 ` Guillermo
2019-05-10  2:38 ` Laurent Bercot
2019-05-10  4:52   ` Dewayne Geraghty
2019-05-10 14:23     ` Laurent Bercot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emcf4a5bbd-94bf-4f58-96d5-ea422a73b8ce@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=dewayne.geraghty@heuristicsystems.com.au \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).