{"id":1962,"date":"2023-08-23T06:14:40","date_gmt":"2023-08-23T06:14:40","guid":{"rendered":"http:\/\/www.msinterdev.org\/wp\/2023\/08\/23\/process-properties\/"},"modified":"2023-08-23T06:14:40","modified_gmt":"2023-08-23T06:14:40","slug":"process-properties","status":"publish","type":"post","link":"http:\/\/www.msinterdev.org\/wp\/2023\/08\/23\/process-properties\/","title":{"rendered":"PROCESS PROPERTIES"},"content":{"rendered":"

PROCESS PROPERTIES<\/h1>\n

LimitCPU=<\/em>, LimitFSIZE=<\/em>, LimitDATA=<\/em>, LimitSTACK=<\/em>, LimitCORE=<\/em>, LimitRSS=<\/em>, LimitNOFILE=<\/em>, LimitAS=<\/em>, LimitNPROC=<\/em>, LimitMEMLOCK=<\/em>, LimitLOCKS=<\/em>, LimitSIGPENDING=<\/em>, LimitMSGQUEUE=<\/em>, LimitNICE=<\/em>, LimitRTPRIO=<\/em>, LimitRTTIME=<\/em><\/p>\n

Set soft and hard limits on various resources for executed processes. See setrlimit(2)<\/a> for details on the process resource limit concept. Process resource limits may be specified in two formats: either as single value to set a specific soft and hard limit to the same value, or as colon-separated pair soft:hard<\/strong> to set both limits individually (e.g. “LimitAS=4G:16G”). Use the string infinity<\/strong> to configure no limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits measured in bytes (e.g. “LimitAS=16G”). For the limits referring to time values, the usual time units ms, s, min, h and so on may be used (see systemd.time(7)<\/a> for details). Note that if no time unit is specified for LimitCPU=<\/em> the default unit of seconds is implied, while for LimitRTTIME=<\/em> the default unit of microseconds is implied. Also, note that the effective granularity of the limits might influence their enforcement. For example, time limits specified for LimitCPU=<\/em> will be rounded up implicitly to multiples of 1s. For LimitNICE=<\/em> the value may be specified in two syntaxes: if prefixed with “+” or “-“, the value is understood as regular Linux nice value in the range -20…19. If not prefixed like this the value is understood as raw resource limit parameter in the range 0…40 (with 0 being equivalent to 1).<\/p>\n

Note that most process resource limits configured with these options are per-process, and processes may fork in order to acquire a new set of resources that are accounted independently of the original process, and may thus escape limits set. Also note that LimitRSS=<\/em> is not implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource controls listed in systemd.resource-control(5)<\/a> over these per-process limits, as they apply to services as a whole, may be altered dynamically at runtime, and are generally more expressive. For example, MemoryMax=<\/em> is a more powerful (and working) replacement for LimitRSS=<\/em>.<\/p>\n

Note that LimitNPROC=<\/em> will limit the number of processes from one (real) UID and not the number of processes started (forked) by the service. Therefore the limit is cumulative for all processes running under the same UID. Please also note that the LimitNPROC=<\/em> will not be enforced if the service is running as root (and not dropping privileges). Due to these limitations, TasksMax=<\/em> (see systemd.resource-control(5)<\/a>) is typically a better choice than LimitNPROC=<\/em>.<\/p>\n

Resource limits not configured explicitly for a unit default to the value configured in the various DefaultLimitCPU=<\/em>, DefaultLimitFSIZE=<\/em>, … options available in systemd-system.conf(5)<\/a>, and – if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user services, see below).<\/p>\n

For system units these resource limits may be chosen freely. When these settings are configured in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be used to raise the limits above those set for the user manager itself when it was first invoked, as the user’s service manager generally lacks the privileges to do so. In user context these configuration options are hence only useful to lower the limits passed in or to raise the soft limit to the maximum of the hard limit as configured for the user. To raise the user’s limits further, the available configuration mechanisms differ between operating systems, but typically require privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by setting limits on the system service encapsulating the user’s service manager, i.e. the user’s instance of user@.service. After making such changes, make sure to restart the user’s service manager.<\/p>\n

Table 1. Resource limit directives, their equivalent ulimit shell commands and the unit used<\/strong><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Directive<\/strong><\/td>\nulimit<\/strong> equivalent<\/td>\nUnit<\/strong><\/td>\nNotes<\/strong><\/td>\n<\/tr>\n
LimitCPU=<\/td>\nulimit -t<\/td>\nSeconds<\/td>\n–<\/td>\n<\/tr>\n
LimitFSIZE=<\/td>\nulimit -f<\/td>\nBytes<\/td>\n–<\/td>\n<\/tr>\n
LimitDATA=<\/td>\nulimit -d<\/td>\nBytes<\/td>\nDon’t use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax=<\/em> in systemd.resource-control(5)<\/a>.<\/td>\n<\/tr>\n
LimitSTACK=<\/td>\nulimit -s<\/td>\nBytes<\/td>\n–<\/td>\n<\/tr>\n
LimitCORE=<\/td>\nulimit -c<\/td>\nBytes<\/td>\n–<\/td>\n<\/tr>\n
LimitRSS=<\/td>\nulimit -m<\/td>\nBytes<\/td>\nDon’t use. No effect on Linux.<\/td>\n<\/tr>\n
LimitNOFILE=<\/td>\nulimit -n<\/td>\nNumber of File Descriptors<\/td>\nDon’t use. Be careful when raising the soft limit above 1024, since select()<\/strong> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use select()<\/strong>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use MemoryMax=<\/em> to control overall service memory use, including file descriptor memory.<\/td>\n<\/tr>\n
LimitAS=<\/td>\nulimit -v<\/td>\nBytes<\/td>\nDon’t use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax=<\/em> in systemd.resource-control(5)<\/a>.<\/td>\n<\/tr>\n
LimitNPROC=<\/td>\nulimit -u<\/td>\nNumber of Processes<\/td>\nThis limit is enforced based on the number of processes belonging to the user. Typically it’s better to track processes per service, i.e. use TasksMax=<\/em>, see systemd.resource-control(5)<\/a>.<\/td>\n<\/tr>\n
LimitMEMLOCK=<\/td>\nulimit -l<\/td>\nBytes<\/td>\n–<\/td>\n<\/tr>\n
LimitLOCKS=<\/td>\nulimit -x<\/td>\nNumber of Locks<\/td>\n–<\/td>\n<\/tr>\n
LimitSIGPENDING=<\/td>\nulimit -i<\/td>\nNumber of Queued Signals<\/td>\n–<\/td>\n<\/tr>\n
LimitMSGQUEUE=<\/td>\nulimit -q<\/td>\nBytes<\/td>\n–<\/td>\n<\/tr>\n
LimitNICE=<\/td>\nulimit -e<\/td>\nNice Level<\/td>\n–<\/td>\n<\/tr>\n
LimitRTPRIO=<\/td>\nulimit -r<\/td>\nRealtime Priority<\/td>\n–<\/td>\n<\/tr>\n
LimitRTTIME=<\/td>\nulimit -R<\/td>\nMicroseconds<\/td>\n–<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

PROCESS PROPERTIES LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME= Set soft and hard limits on various resources for executed processes. See setrlimit(2) for details on the process resource limit concept. Process resource limits may be specified in two formats: either as single value to set a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[3633,3634,3635,3636,3637,3638],"class_list":["post-1962","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-file-descriptor","tag-limitnofile","tag-umit","tag-3636","tag-3637","tag-3638"],"_links":{"self":[{"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/posts\/1962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/comments?post=1962"}],"version-history":[{"count":0,"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/posts\/1962\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/media?parent=1962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/categories?post=1962"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.msinterdev.org\/wp\/wp-json\/wp\/v2\/tags?post=1962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}