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: . (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.