I'm configuring my linux to use s6-rc. It works fairly well so far. One thing I want to improve though, is that the early logger logs to /run/uncaught-logs. It's nice to have a log file during early boot and it helped my debugging easier. But it would be cool to able to change the location to a permanent location like /var/log after the root has been remounted as read-write.
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.
Is it possible to update the log path of early/catch-all s6-log process to a new location, and perhaps copying the early logs there as well? Or if not, is it possible to spawn a new s6-log process that acts as a catch-all logger?
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. But in practice you would add complexity to the log infrastructure, and you need to pay close attention to all the failure cases because you don't want to have a broken catch-all logger for any reason at all. I don't think the benefits are worth the additional effort; but feel free to disagree and write such a "log mover" service.
BTW, is there a command to restart service managed by s6-rc? I've been using "s6-rc -v2 -d change sv && s6-rc -v2 -u change sv" but I feel there might be something simpler.
For oneshots, no - but you rarely want to "restart" oneshots. For longruns, unless you want to also restart everything that depends on the service, you can just bypass the s6-rc layer and directly tell s6 to restart your process: s6-svc -r /run/service/$sv Hope this helps, -- Laurent
