I’m helping a customer snap a large project that writes many syslog files to /var/log/THEPROJECT/* (via golang syslog at least).
Is there a way to configure syslog to use (for this snap) a base directory in SNAP_DATA? (or grant write access to the log paths)?
Perhaps the core-support interface allows this?
Cheers
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?
In addition to what @jamesh pointed out, core-support is definitely not an option. As the name indicates, this is an interface focused on making core itself work.
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)
I’m still trying to see a use case for this though. If a snap wants to put log files in a location it can write to, why does it need to involve syslogd?
And if it is going to use syslogd, isn’t it actually a feature that the logs end up in a location the snap can’t modify?
because you dont want to patch the upstream code that has calls to “logger” everywhere in its code ?
i agree though that it is best to simply log to SNAP_DATA, but some SW might not easily support that …
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 is exactly the limitation for the customer, you understand the requirements very well ogra.
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
It is allowed by default-- /dev/log, logger command and all the journald sockets.
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?
the path is actually clear (/etc/rsyslog.d), we’d need some addition to the core configuration hook that would turn a
snap set extra-log-filters="foobar"
into a proper filter rule for syslog to create a dedicated log file …
right now all your customers log entriies would simply land in the general syslog file …
Seems reasonable to me. Is this something that has already been added to the roadmap or something that would need consideration still before any specific design and implementation commence?