[systemd-devel] I want to use an environmental variable for LimitNOFILE= in a service unit. Is it possible?

[Reindl Harald]

Am 03.09.2015 um 19:08 schrieb Eliezer Croitoru:
> I noticed it doesn't work.
> And well since I am building an RPM the only option I can think of is
> either use a custom startup script which will set the limits manually or
> define the service as a config file in the RPM.
>
> Maybe you have some experience with overwriting the service files with
> RPMS, maybe there is some kind of practice use for this?
>
> The main issue is that if I hardcode it in the service file the RPM will
> replace it each and every time.
> If I will use it as a config file it will stay the same and it might be
> the better solution.
> Seeking after thought and ideas on the best way to implement it.

RPM packages are suppused to ship systemdunits below 
/usr/lib/systemd/system and custom overrides are supposed to copy the 
unit to /etc/systemd/system/ with the same name

> On 03/09/2015 18:35, Lennart Poettering wrote:
>> On Thu, 03.09.15 17:45, Eliezer Croitoru (eliezer at ngtech.co.il) wrote:
>>
>>> Hey,
>>>
>>> I am working on a service for squid caching service.
>>> I have a need to define LimitNOFILE from an environmental variable
>>> instead
>>> of only the service file.
>>
>> No this does not work. Environment expansion is only done for
>> ExecStart= and related lines, and the environment is only determined
>> right when the binary is invoked.
>>
>> Generally: configuration for units is supposed to be placed in units,
>> Splitting that into environment files such as /etc/sysconfig/* makes
>> things both more opaque for the admin and harder to process from
>> applications reading unit files. Hence, your usecase is explicitly
>> something we don't recommend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150903/8cf45793/attachment.sig>