A service is started by systemd, and that is where it gets its limits.
systemd takes the limits from the unit file: the LimitNOFILE=64 line in the [Service] section sets both of the shipper's limits. Without such a line, a service gets systemd's default limits: 1024 soft and 524288 hard. That is why ulimit in your shell and /etc/security/limits.conf have no effect on services: limits.conf is read by the programs that log you in, and systemd does not read it.
The shipper's unit file lives in /usr/lib/systemd/system: the package owns it there, and a package update will overwrite any edit in it. Your own value goes into a drop-in — a /etc/systemd/system/<unit>.d/<name>.conf file that systemd reads on top of the main one; that is how you raised MemoryMax in the memory lesson. systemctl cat <unit> shows both files in order, and sudo systemctl edit <unit> opens a drop-in in an editor.
A limit change passes three places: the file, the description in systemd after daemon-reload, and the process after a restart. systemctl show -p LimitNOFILE <unit> shows the description, /proc/<PID>/limits shows the process. Until the service is restarted, the process keeps running with the old limit.
Raise the shipper's limit
Raise the open-file limit of the lab-shipper collector to 4096 so that the change survives a package update: leave the unit file in /usr/lib/systemd/system as it is. The running shipper must get the new limit.
Goals · 0 of 2
- Set the 4096 limit in a drop-in on top of the package file not done yet
- Give the new limit to the running shipper not done yet