I have a snap with a daemon that needs more file descriptors than the default 4k limit.
I need to add something like LimitNOFILE=100000 to the service file in order to operate the service properly.
I can edit this by hand – or even automate this orchestration – but I’m wondering:
Will it get clobbered by snapd? My gut feeling says “yes”…
Is there a way to properly define systemd customizations that a snap needs?
I can’t imagine all possible snap daemon use cases can (or should) be modeled by some snapcraft.yaml abstraction. There should be a way to inject custom directives into systemd files.
If you’re just hitting the soft limit rather than hard, it might be better for your app to raise its own limit. You could try something similar to what dbus-daemon does:
If you are running into problems with a hard limit or don’t control the snap’s source, you might be best off adding a drop-in file to augment the service file snapd wrote out. You’re correct that editing the service file produced by snapd is likely to be undone next time the snap upgrades.
If the service is called snap.snapname.servicename.service, create a directory /etc/systemd/system/snap.snapname.servicename.service.d, and create a file in that directory named set-file-limit.conf` with content like:
[Service]
LimitNOFILE=...
This allows you to override the limit in a way that will survive upgrades, and won’t leave a zombie unit behind if you uninstall the snap.
I have a SNAP package of 3 daemons, and I need to restart all other services if one of them fails.
I have read the manual and not found systemd features like “partof=”
Is there any way to get expected behavior?