The way I was thinking about it was, a disabled syslogger is still part of core and enable-able, therefore the interfaces don’t need to change, the system need only be configured to enable traditional log file locations. System builders can set the core option and get what they need, and interested snaps could be adjusted to alert that it needs to be enabled. A mechanism could be provided to allow other snaps to enable core logging setting.
If there is no logger like rsyslog in core, then the interfaces probably do need to change because the log files in question are not provided by core (but are on classic). On core, the log files would instead be provided by another snap (eg, the rsyslog snap), so we’d need to think about if that requires more changes to log-observe or a new interface. System builders could preinstall this snap and snaps could be adjusted to alert that another snap needs to be installed. Depending on where those log files live, those snaps may need code changes for the new location. As things are currently implemented, there is no possibility for a mechanism for snaps to enable traditional logging because there is nothing to enable.
Disabling or removing, knowing what snaps plug log-observe is important to know what may break immediately. IIRC, there are commercial projects that expect the traditional locations.
@jdstrand as far as I can tell we have 3 snaps with granted log-observe, one is snappy-debug, one is for screenly (which is asking for the disabling) and then there’s another one
The fact we won’t be shipping logs into the same location won’t break any software. They will stop observing new logs on disk, which is the obvious and intended consequence of disabling or removing such a service. We should of course publicly inform people that this is being done and why (in addition to this thread), but I see that change as a very positive one considering it will prevent wearing solid state devices out, and will also prevent unattended systems from crashing due to disks full of logs. That Ubuntu thread that reached an agreement on doing this exact change also seems to back this as a good choice. The point made above about there being almost no users of this interface is an excellent data point as well.
So, my vote for us to move on and remove rsyslog from core altogether, and then start working on a syslog snap, preferably together with someone that in fact depends on this feature instead of someone that would just develop it on a theoretical basis.
