Thanks for all the replies :)
> Your requirements of saving logs from /run/uncaught-logs and (mentioned
> later) batch-producing `producer-for'/`consumer-for' files can be
> automated using slew: <https://gitea.com/CasperVector/slew>. (Other
> encapsulations of s6/s6-rc also exist, but I am the author of slew ;)
>
Yeah I'll need to look around and take inspirations from all the s6-rc
wrapper/scripts. Thanks for sharing.
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.
I like the idea of reading /run/services/s6-svscan-log/fifo from a new
logger instance, I might try it and see how it works.
In 66 this is written as /run/66/log/0/current, and I have user/root
> copy it after a shell is executed, this helps when I would change
> something and it is not booting right on the next boot, I can compare
> the before after. Part of 66 booting procedure is to activate tty12 as
> early as possible, instead of the insecure sulogin that appears in
> runit. From tty12 you can read that log and mount things manually and
> change/fix what is wrong. You can also decrease/increase verbosity in
> that log. tty12 is a special setup in 66 where root can't login, only a
> user can, a security measure I find as a great idea.
>
Have verbose log in tty12 is a great idea, I'll see how 66 does it and
maybe implement it in my setup.
Received on Sun Sep 06 2020 - 15:53:48 UTC