May we please have autoconnect for the following system-files plug?
frame-systemd:
interface: system-files
write:
- /etc/systemd/system
It’s quite a sledgehammer, but I need to create the /etc/systemd/system/snap.${SNAP_INSTANCE_NAME}.daemon.service.d/ directory, and hence need that big of an opening.
EDIT:
And for a bit more context: we need this to add relationships between the Frame daemon and Plymouth to enable smooth booting by default:
This feels like a very big sledgehammer - it allows the ubuntu-frame snap to completely escape confinement. Instead I feel that this should ideally be managed more directly by snapd which would create such a file on behalf of your snap - via a new interface like plymount-control or some-such. Can you please discuss this first with the snapd team? FYI @pedronis @ernestl.
I’d go even further and add something like allow-overrides: to the daemon: definition… this would then create the .d subdirectory in /etc/systemd/system for the specific app instance and automatically grant write access to this subdir… instead of using an interface at all…
@ogra right, but that’s what Alex is about. Being able to override random parts of the service allows you to run whatever you want out of confinement. So it would not really be more strict.
A new plymouth-control interface would sure help, but then I still need to prevent plymouth-quit.service from activating, and again that probably can’t be random conflicts: on the daemon. Maybe plymouth-control implies conflicting with plymouth-quit.service?
The cleanest solution to this would be a generalization of the ideas we sketched at some point related to cross-snap service dependencies, we are aware of other use cases where the cross dependency/control would be instead from snap to system services/targers. This area has been in our backlog for a long time but hasn’t quite yet made the top of the queue so far.
Some form of “plymouth-control/override” interface could be a workable shorter-term solution.
@Saviq hey,
Following up on this request… it seems the best path forward is working on a new interface? If that’s the case maybe this topic can be moved to the snapd category or a new one can be created. If this is correct, I will proceed to remove this request from our review queue. Thanks!
Hi @emitorino yes, feel free to close. Don’t think it makes sense to move this topic, we’ll refer to it when we get to the new interface.