Skip to main content ↑ ↓
Topic: Migrating to s6-log (Read 1797 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Migrating to s6-log

This is a somewhat major internal change. Although it shouldn't affect users too much, I thought it was worth announcing. Artix's s6's implementation will be moving towards using s6-log. Some pieces of this have been implemented in system already and currently the scripts in gremlins make use of this function.

To put it simply, s6 has the capability of reading logs from every s6-rc service. We intend to make full use of this since it has several advantages over traditional, syslog daemons. Syslog sends logs from every service to one centralized place which can be slow, buggy, and in some cases even crash your system (see the syslog-ng bug that prevented boot). s6-log is a simple, reliable way to capture all the logs you want from a service and lets you completely avoid all of syslog's problems. It also nicely handles log rotation so there's no need to worry about that either.

Every s6 long runservice will be installed with a service_name-srv and service_name-log directory. As the names imply, the srv directory is what actually runs the daemon while the log directory catches the logs from that daemon in the pipeline. The s6-log options for every daemon can be configured in the service_name-log/conf file. Just follow the noted format. The general naming you use to interact with s6-rc remains the same as it was before, service_name. This is because s6-rc allows you to declare a pipeline-name which automatically bundles a daemon and its logging service together. So nothing changes on this front.

Observant s6 users may notice that they have an s6log user and group now. This is intentional. There is no reason to run the logging services as root. Instead, they are run as the s6log user. The logs are written to the /var/log/service_name which is also accessible to anyone in the s6log group. So simply just add any users to the s6log group if you want to them to have access to logs.

Of course, you are still welcome to use syslog-ng-s6 or metalog-s6. Neither of those will go away. However, the log bundle that is currently being used to make sure those services (if they exist) startup up first will eventually be removed in favor of the s6-log approach. There is no hard timetable on this, but once the major, important services are all ported over to this new scheme, that bundle will be removed from s6-scripts.

Important note: This is a bit unfortunate, but the directory names change. This means services will shutdown and then restart on the s6-rc-update call that occurs when you install or upgrade a script from the repos. For most things this doesn't matter, but you will likely lose your graphical session when updating to dbus-s6-20200125 and elogind-s6-20200127.

Edit: Okay the dbus-s6-20200128 and elogind-s6-20200128 packages now display warnings while updating and require user intervention to continue. I believe these are the only two packages where restarting the service can be disastrous (i.e. losing work). When I finish up the rest of the system services, I will start to move things out of testing and into stable.

Re: Migrating to s6-log

Reply #1 –
The first big batch of these have now been pushed to stable. That should cover most scripts people actually use. Hopefully I'll be able to finish up the rest by the end of the week. I'll update the wiki accordingly.

Re: Migrating to s6-log

Reply #2 –
How will syslog output from non-supervised (or supervised but not yet ported to s6-log) programs be handled? Will a "legacy" syslog daemon still be needed for these?

Re: Migrating to s6-log

Reply #3 –
Yeah for those you'll still need a syslog daemon of some sort if you want to capture their output in some place. I don't think you should have any non-supervised daemons though? That sort of defeats the whole purpose of process supervision.

Re: Migrating to s6-log

Reply #4 –
True, though I personally have found syslog useful in X "daemons". But perhaps now is a good time to start using a user s6 service tree for those.

Anyway, if I am not mistaken, s6-log only captures stdout. So, at minimum, stderr should be redirected to stdout. Also, there might be daemons that only log to syslog and not on stdout/stderr, or log less on stdout/stderr. Logs on stdout/stderr also looses the metadata associated with syslogs; priority being the most important one in my opinion.

The s6-log documentation describes how one can setup s6 as a syslog daemon.

What I think I'd like to see is this being implemented as an optional service. That would allow one to catch syslogs, but without requiring extra tools (like syslog-ng).

Regardless of which syslog daemon one has running, services that has a working s6-log setup should probably be configured to *not* log to syslog, when possible, to reduce duplicate logs.

Does this make sense?

All in all, I'm really liking this though. Depending on where I end up with my own syslog needs, I might start looking at using s6 as a syslogd replacement, assuming you'd be willing to accept such a contribution. Unless that is something you'd prefer to implement yourself in which case I'd happily let you  :D

Thanks, again, for doing this!

*Edit: s6-log reads stdout, not stderr.

Re: Migrating to s6-log

Reply #5 –
Some good points there. A simple "fdmove -c 2 1" should take care of the redirections, so that should be easy enough to do.

To be quite honest, I'm not really an avid syslog user so breaking a few things was not too much of a deterrent for me. But yeah I'll see if I can implement some of these things. s6 does have its own syslog replacement. That may come in handy.