supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Casper Ti. Vector" <caspervector@gmail.com>
To: supervision@list.skarnet.org
Subject: A program that can get exactly the log of a supervised process?
Date: Sun, 24 Oct 2021 00:03:01 +0800	[thread overview]
Message-ID: <YXQyNQbpPZBKYLXC@CasperVector> (raw)

Many daemons output some lines in their logs (here assumed to have been
redirected to logging pipes in some supervision framework) that can be
used as a kind of markers for readiness.  So if we can implement the
following program, we will able to trivially add readiness support to
these daemons without patching their source code, while reducing the
daemon-specific code (the pattern recogniser) to a minimum:

* The program is double-forked from the ./run script of a service, and
  also watches for the death of the daemon: in case the daemon dies
  before logging the readiness marker (and optionally, if a specified
  timeout is reached), this program dies as well, killing its subprocess
  (the pattern recogniser, discussed below).  To maximise portability
  across supervision frameworks, the death notification can be
  implemented with a pipe that can be written to by an ancillary
  program ran from the ./finish script.

* The program somehow (directly or indirectly) gets a copy of the
  log from the reading side of the logging pipe, and feeds it into a
  specified pattern recogniser, which should exit 0 upon finding the
  readiness marker.  A special exit value of the subprocess can be
  considered a notification for fatal error erroneously ignored by the
  daemon, leading to the program exiting some special value which can
  be handled by a `s6-svc -t' invocation.  In order to avoid potential
  feedback loops, the subprocess should be killed (and waited for)
  before the program outputs any warning; the subprocess should be
  responsible for keeping itself quiet when running normally.

Any idea on how the log "teeing" may be done cleanly (and portably
if possible; something akin to `tail -f' seems unsuitable because of
potential log rotation), and perhaps any flaw or redundancy in the
design above?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


             reply	other threads:[~2021-10-23 16:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-23 16:03 Casper Ti. Vector [this message]
2023-06-22 17:44 ` Casper Ti. Vector
2023-06-22 19:39   ` Casper Ti. Vector
2023-06-22 19:43     ` Casper Ti. Vector
     [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
2021-10-25 12:57       ` Rio Liu
2021-10-25 13:26         ` Laurent Bercot
2021-10-25 16:00       ` 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=YXQyNQbpPZBKYLXC@CasperVector \
    --to=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).