Re: Update early logger logging path after remounting root as rw

From: Samuel Holland <samuel_at_sholland.org>
Date: Sat, 5 Sep 2020 15:50:03 -0500

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.
Received on Sat Sep 05 2020 - 20:50:03 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC