You spend half an hour tuning your ulimits and nice values, you restart the service, and then you check it with prlimit. It is still showing the defaults. You assume systemd read your drop-in file, but it didn’t. This bit me in prod during a memory leak hunt when the service hit a hard cap I thought I had raised. It is frustrating, but the fix is rarely about the limits themselves—it is about how the unit file interacts with the execution environment.

The trap of the unit file reload

Most of us forget that systemd isn’t just a shell script runner. When you change a configuration file in /etc/systemd/system/, simply restarting the service won’t cut it. You have to tell the init system that the unit definition itself has changed. If you skip the reload, you are debugging an old version of your service configuration while looking at the new one on your screen.

systemctl daemon-reload
systemctl restart my-service.service
prlimit -p $(systemctl show -p MainPID --value my-service.service)

• Always run daemon-reload before restarting after any change to unit files
• Check systemd-analyze verify to catch syntax errors before they hit production
• Use systemctl show to verify the effective configuration rather than trusting your editor

When hardening blocks your tuning

Sometimes the limits aren’t being ignored—they are being superseded by security directives. If you have ProtectControlGroups or PrivateDevices enabled, systemd might be imposing stricter internal caps that override your LimitNOFILE or LimitMEMLOCK settings. When you see a service failing with resource exhaustion despite your config, check the cgroup state manually. That is usually where the truth hides.

Stop guessing why your process died. If you check the cgroup files directly, you will see exactly what the kernel enforced. Keep an eye on your service’s peer-to-peer communication—often, the limit isn’t at the service level, but at the namespace level. Next time you see a mysterious failure, check the kernel log and dump the cgroup limits; you will save yourself a lot of time.