How to customize systemd service created by snapd?

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.

you can use a command-chain entry in your daemon startup setup to call ulimit instead …

1 Like

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:


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.

1 Like

I changed my slurm settings for ulimit using this method, but using systemd internal tools for doing this as below:

  • Modify (/etc/systemd/system/snap.slurm.slurmd.service.d/override.conf) with systemctl edit as:

sudo systemctl edit snap.slurm.slurmd.service

  • Reload systemctl daemon (not sure its needed, but I did it like this):

sudo systemctl daemon-reload

  • Finally, restarting the service itself:

sudo systemctl restart snap.slurm.slurmd.service

Then, using the pid of the running service, I can validate that the ulimits are what I expect:

cat /proc/19973/limits