Is it actually using syslog, or writing its own log files?
If it is using syslog, then you just need to be able to talk to /dev/log (which is generally a symlink, so probably also the target of that link). It’d then be up to the daemon listening on that socket to decide where to write the log files (or even be configured to send the logs to another system over the network). I don’t think there is an interface that allows this yet.
If the process is running as a daemon under systemd though, it should already be able to write to the system log by simply writing to stderr though.
If it is writing the log files itself, then presumably it could be modified to write them to some other location, or be modified to use one of the above options?
I could imagine to have a “snap-log” interface that actually makes snapd put a snippet into /etc/rsyslog.d/ at snap install time which makes logs for the specific snap autmatically go to $SNAP_DATA/log and also allows the snap to talk to logger…
While the syslog side here is easy, you would need to make sure to have a proper pattern you can match on for the specific snap logs …
As a quick and dirty option i’d just use some self shipped service in the snap that simply logs to the writable area and not use the system logger at all … (like … modify the golang syslog you use)
Right, but if it is using syslog for logging how would it know where its logs will end up in the first place?
Getting back to the original question: if the software is doing its own logging and is hard coded to try and write its logs to a location under /var/log/..., one forward looking solution would be to use the layouts feature when it is landed. This would let you bind mount /var/log (or a subdirectory under it) to a writable location from the perspective of the snap’s mount namespace. That might not be so helpful if you’re after a solution that works right now though.
if it properly uses logger in its code it does not need to know, syslog cares for this … (and i assume the golang syslog will properly use this)
if it doesnt use syslog at all and hardcodes writing to /var/log/someplace.log this indeed doesnt apply at all …
typically the reason to use syslog’s logger is to actually be able to configure it via syslog patterns that you can adjust via additional config snippets (see /etc/rsyslog.d/50-default.conf … for example)
also, if you had globally configured a central logging server in your datacenter then you could not only have per-snap logs in SNAP_DATA but for example also have per-snap and per-device log files with the interface i suggested above.
i could imagine this makes sense in an IoT setup with say 1000 Ubutu Core devices managing your factory and one central entity for managing and logging
Do keep in mind that rsyslog may not even be running on Ubuntu Core devices (though journald would be running), so exposing rsyslog configuration to snaps is probably not ideal, since they would not be able to configure the core snap to ensure rsyslog was started.
If this were going to be implemented, I wonder if it would be better exposed as a core config option that the admin and/or gadget snaps could then set.
Yes, this exactly would fulfill the customer requirements in this case. How hard would this be to prototype? They are using rsyslog for logging on their system today and would like to continue using it under Core.
This would also satisfy the customer requirements and actually sounds quite a bit more flexible as it provides for a very generic interface for logging in general. What do others think of this specific idea?
this would surely fulfill the requirement for setting up /etc/rsyslog.d, we’d still need an interface that allows calling logger or attaching to /dev/log though (or is that allowed already, i dont remember)…
i think the only thing we have today is log-observe which only allows reading
Ok, so basically the proposal then is to add a method for an admin and/or gadget snap that could set a core config option which would contain a path of where to look for a custom rsyslog config file. Am I understanding your proposal @jdstrand correctly? Would anything else be required?