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: "Casper Ti. Vector" <caspervector@gmail.com>,
	supervision@list.skarnet.org
Subject: Re: A program that can get exactly the log of a supervised process?
Date: Mon, 25 Oct 2021 12:37:41 +0000	[thread overview]
Message-ID: <em5f7d56ff-18c6-4902-b5ab-21f5fd4dfc7b@elzian> (raw)
In-Reply-To: <YXUJKWltk+OwYhtf@caspervector>

>Well, I do realise the lifespan issue of the loggrep program, which is
>why I asked the question in the first place.  But I really never thought
>of directly inserting loggrep into the logging chain as a new node;
>instead, what I have thought is making loggrep a program "attachable" to
>the logger.  That is, the logger is extended with a listener which at
>least one client can connect to, and which upon connection tees the log
>to the client.  I do not know whether you have similar ideas.

  Well in theory you could have something like skabus-dyntee
( https://skarnet.org/software/skabus/skabus-dyntee.html ) as your
logger, and have your "real" logger run as a skabus-dyntee client.
Then you could add a loggrep as a second skabus-dyntee client, and it
would just disappear when it has finished its work.

  It would be a little unreliable as is, because skabus-dyntee doesn't
care if it has no client at all, so if the real logger dies, it won't
block the log stream until the real logger has restarted, so you may
lose logs. But apart from that, it would work.

  A really reliable solution would be having a skabus-dyntee equivalent
that has one permanent output and blocks as long as that output isn't
there. As you say, it would be a logger extended with a listener.

  Another question is how to piggyback loggrep into the notification
mechanism: if loggrep is tied to the logger and not to the service,
it doesn't have native access to the notification pipe. That means a
specific mechanism is needed to give it cross-service access.

  That's definitely a lot of code and a lot of architectural
convolutions to accommodate what is ultimately a daemon misdesign.
But it's probably the least bad way to do it, so I might think about it
more and add something like that to s6 in the distant future.

--
  Laurent


  parent reply	other threads:[~2021-10-25 12:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YXQyNQbpPZBKYLXC@caspervector>
2021-10-24  6:20 ` Laurent Bercot
2021-10-24  7:20   ` Casper Ti. Vector
     [not found]   ` <YXUJKWltk+OwYhtf@caspervector>
2021-10-25 12:37     ` Laurent Bercot [this message]
2021-10-25 12:57       ` Rio Liu
2021-10-25 13:26         ` Laurent Bercot
2021-10-25 16:00       ` Casper Ti. Vector
2021-10-23 16:03 Casper Ti. Vector
2023-06-22 17:44 ` Casper Ti. Vector
2023-06-22 19:39   ` Casper Ti. Vector
2023-06-22 19:43     ` Casper Ti. Vector

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=em5f7d56ff-18c6-4902-b5ab-21f5fd4dfc7b@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=caspervector@gmail.com \
    --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).