Is there any sane, accepted way for a strictly confined snap to read systemd journal logs? Specifically, the logs that are tagged by it’s systemd unit designation?
I’ve tried the following:
Augmenting the snap’s systemd service file via a drop-in to redirect stdout and stderr to a file or fd in $SNAP_DATA/$SNAP_COMMON.
- This is not ideal as manual log rotation would be required, journalctl access for the unit would no longer be available, and the drop-in would need to be provided elsewhere and thus would require end-user intervention, as snap install hooks don’t have access that deep into the system.
Using a separate snap to read the logs, then share via the preferred IPC mechanism (a named pipe for example) along with the content interface.
- Since journalctl calls are not permitted (nor is using the systemd journal API directly) from a strict snap, the secondary snap would need to be classically confined. This, according to docs and my own experience, prevents sharing via the content interface.
Augmenting the systemd journal config to forward to syslog, then augment the syslog config to drop the logs of interest into a file in $SNAP_DATA/$SNAP_COMMON
- This “works”, and presumably would handle log rotation, but again requires end-user intervention.
Frankensteining it with a secondary snap, classically confined, (or at this point a script, .deb, whatever) that dumps logs directly to a fifo that it creates inside the primary snap’s $SNAP_DATA.
- Dirty, end-user intervention required to install additional packages and I doubt this would pass peer review if we released to the snap store.
At this point I’m banging my head, quite literally, against my desk Any ideas would be greatly appreciated. While I’m on the topic, is there any reason for not allowing access to journalctl from a strictly confined snap? Could it simply be that it’s apparently not a common use case?