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.
