From: Samuel Holland <samuel@sholland.org>
To: Rio Liu <rio6.liu@gmail.com>, supervision@list.skarnet.org
Subject: Re: Update early logger logging path after remounting root as rw
Date: Sat, 5 Sep 2020 15:50:03 -0500 [thread overview]
Message-ID: <408ccc80-aa66-66cb-12ae-f29e6aba6cc7@sholland.org> (raw)
In-Reply-To: <CAFDeY1YPSGY2Z2XsEhH7GuJMaC_2cVwtZS1YbXhmNsgxxzBR3g@mail.gmail.com>
On 9/5/20 3:26 PM, Rio Liu wrote:
>>
>> Well the catch-all logger is supposed to be just that: a catch-all
>> logger. That means that ideally, every service should have its own
>> dedicated logger, typically writing to /var/log/something, and the
>> catch-all logger is only used for exceptional stuff such as error
>> messages from the supervision tree, so it doesn't matter that its logs
>> are stored under /run.
>>
> So the best practice is that every (long run) services should have a
> "producer-for" and an extra "service-log" service? Sounds like a lot of
> repeating works... perhaps I can use some symblink to do that.
Yes, or you can preprocess your service directories. For example, the script I
use looks for a "logdir" file containing the log directory path, and uses it to
generate the pipeline and logger service:
https://github.com/smaeul/rc/blob/113e9623/update#L48
>> It's difficult to do. It's possible in theory: you could have a oneshot
>> that modifies /run/service/s6-svscan-log/run, replacing the
>> "/run/uncaught-logs" string with the new location you want, then
>> copies /run/uncaught-logs into that new location and restarting the
>> s6-svscan-log service.
>>
>
> Yeah I don't think I'll go that route. Maybe it'll be easier to somehow
> mount root as rw before the logger starts (if it's actually easier), or
> just boot with rw root if I really need those logs to be saved.
There are a couple of other options I can think of:
1) Bring up a second service reading from the same
/run/service/s6-svscan-log/fifo pipe, and once the new logger is ready, bring
down the old s6-svscan-log service (from a oneshot depending on the new logger).
During the transition, log lines could go to either service, but nothing would
be lost.
2) Keep logging to /run/uncaught-logs, but also copy the logs to /var in a way
that doesn't interfere with the s6-svscan-log service. This could be running
`tail -f` on /run/uncaught-logs/current, or periodically `rsync`ing the whole
directory to /var.
next prev parent reply other threads:[~2020-09-05 20:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-05 15:46 Rio Liu
2020-09-05 19:45 ` Laurent Bercot
2020-09-05 20:26 ` Rio Liu
2020-09-05 20:50 ` Samuel Holland [this message]
2020-09-06 10:36 ` yianiris
2020-09-06 15:53 ` Rio Liu
2020-09-05 20: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=408ccc80-aa66-66cb-12ae-f29e6aba6cc7@sholland.org \
--to=samuel@sholland.org \
--cc=rio6.liu@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).