| Summary: | Support environment as value of resource limits, or any value for that matter | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Alon Bar-Lev <alon.barlev> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED WONTFIX | QA Contact: | systemd-bugs |
| Severity: | enhancement | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Alon Bar-Lev
2013-04-05 09:12:25 UTC
Sorry, I don't understand a word, can you elaborate please? (In reply to comment #1) > Sorry, I don't understand a word, can you elaborate please? Sure. For example, the value of: LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME= Why can't I use ${env} as value? Why does systemd limit the use of these variables to specific attributes? Well, Environment= set environment variables, and we allow referenceing them with $FOO in command lines. But LimitCPU= is not an environment variable... We have no intention to make systemd unit files a second shell language, so I am very conservative in adding more expansions than we already have unless there is a really really strong usecase for it. (In reply to comment #3) > Well, Environment= set environment variables, and we allow referenceing them > with $FOO in command lines. But LimitCPU= is not an environment variable... > > We have no intention to make systemd unit files a second shell language, so > I am very conservative in adding more expansions than we already have unless > there is a really really strong usecase for it. The use case is simple, allowing a user to manage environment file to effect unit behaviour, without the need to re-sync the entire unit every upgrade. Well, but our intention is that people just change the unit files, instead of adding numerous other levels of configuration. Also note that users can easily extend unit files without touching them using .d/ drop-ins. To make this clear: we want unified configuration of units for common properties like resource limits, and not per-service configuration files that all work differently. So I am really convinced that we don't want what you are suggesting. Sorry. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.