Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #177551 > unrolled thread

Best way to set maximum number of open descriptors for a process

Back to article view | Back to linux.debian.user

Contents

  Best way to set maximum number of open descriptors for a process Daniel Bareiro <daniel-listas@gmx.net> - 2017-02-08 12:30 +0100
    Re: Best way to set maximum number of open descriptors for a process <tomas@tuxteam.de> - 2017-02-08 12:50 +0100
      Re: Best way to set maximum number of open descriptors for a process Daniel Bareiro <daniel-listas@gmx.net> - 2017-02-08 13:30 +0100
        Re: Best way to set maximum number of open descriptors for a process Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-08 14:30 +0100
          Re: Best way to set maximum number of open descriptors for a process Daniel Bareiro <daniel-listas@gmx.net> - 2017-02-08 16:40 +0100
            Re: Best way to set maximum number of open descriptors for a process Sven Hartge <sven@svenhartge.de> - 2017-02-08 18:40 +0100
              Re: Best way to set maximum number of open descriptors for a process Daniel Bareiro <daniel-listas@gmx.net> - 2017-02-09 00:30 +0100

#177551 — Best way to set maximum number of open descriptors for a process

[Multipart message — attachments visible in raw view] — view raw

Hi!

I would like to set the maximum number of open descriptors for a
specific process in a way that is maintainable.

I've tried putting something like this in /etc/security/limits.d/:

jvb    soft    nofile   10240
jvb    hard    nofile   10240

But this seems to only apply to processes with an active shell in the
system:

----------------------------------------------------------------------------
root@conference:~# cat /etc/security/limits.d/jitsi-meet.conf
jvb     soft    nofile  10240
jvb     hard    nofile  10240
----------------------------------------------------------------------------
root@conference:~# ps -u jvb | tail -1 | awk '{ print $1 }'
434
----------------------------------------------------------------------------
root@conference:~# cat /proc/434/limits | grep open
Max open files            4096                 4096                 files
----------------------------------------------------------------------------
root@conference:~# su - jvb
jvb@conference:~$ ulimit -n
10240
----------------------------------------------------------------------------

Maybe I could add something to the startup script, but maybe if the
Debian package is updated, these changes will be lost. What do you
suggest is the best way?


Thanks in advance.

Kind regards,
Daniel

[toc] | [next] | [standalone]

#177553

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Feb 08, 2017 at 08:28:33AM -0300, Daniel Bareiro wrote:
> Hi!

[...]

> Maybe I could add something to the startup script, but maybe if the
> Debian package is updated, these changes will be lost. What do you
> suggest is the best way?

Yes, if the process is being started via a shell, ulimit seems the
way to go. In SysV init, either in the start script or perhaps in
/etc/defaults (which is then picked up by the start script).

Note that /etc is "taboo" for the distro[1], i.e. it will install
something there, but in won't touch anything which wasn't installed
by the distro, at least not without asking.

Sure systemd has a way to do that, but for that I'll have to defer
to the systemd experts.

[1] at least for civilised distros, like Debian.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlibBBUACgkQBcgs9XrR2kb0vQCeIx9lRmmoiZCT4bRjpyovQJBf
CVcAni3kA4bZLHnCGlqayf6mqQ9uml7W
=eX51
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#177554

[Multipart message — attachments visible in raw view] — view raw

Hi, Tomas.

On 08/02/17 08:42, tomas@tuxteam.de wrote:

>> Maybe I could add something to the startup script, but maybe if the
>> Debian package is updated, these changes will be lost. What do you
>> suggest is the best way?

> Yes, if the process is being started via a shell, ulimit seems the
> way to go. In SysV init, either in the start script or perhaps in
> /etc/defaults (which is then picked up by the start script).
> 
> Note that /etc is "taboo" for the distro[1], i.e. it will install
> something there, but in won't touch anything which wasn't installed
> by the distro, at least not without asking.
> 
> Sure systemd has a way to do that, but for that I'll have to defer
> to the systemd experts.
> 
> [1] at least for civilised distros, like Debian.

The process starts as a service, so it does not require a shell:

-----------------------------------------------------------------------
root@conference:~# systemctl status jitsi-videobridge
● jitsi-videobridge.service - LSB: Jitsi Videobridge
   Loaded: loaded (/etc/init.d/jitsi-videobridge)
   Active: active (running) since Tue 2017-02-07 08:25:10 ART; 24h ago
  Process: 410 ExecStart=/etc/init.d/jitsi-videobridge start
(code=exited, status=0/SUCCESS)
   CGroup: /system.slice/jitsi-videobridge.service
           └─434 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp
-Djava.library.path=/usr/share/jitsi-videobridge/lib/native/linux-64 -...

Warning: Journal has been rotated since unit was started. Log output is
incomplete or unavailable.
-----------------------------------------------------------------------

I had thought that I could add something to the script that starts the
process, but I'm not sure if it's the best idea from the point of view
of maintainability because a package update could eliminate that change.

Another alternative might be to add something like this to /etc/rc.local:

-----------------------------------------------------------------------
PID_JVB=`ps -u jvb | tail -1 | awk '{ print $1 }'`
prlimit --pid $PID_JVB --nofile=10240:10240
-----------------------------------------------------------------------

But perhaps there is another more elegant way to achieve this.


Thanks for your reply.

Kind regards,
Daniel

[toc] | [prev] | [next] | [standalone]

#177555

On Wed, Feb 08, 2017 at 09:26:14AM -0300, Daniel Bareiro wrote:
> The process starts as a service, so it does not require a shell:

> I had thought that I could add something to the script that starts the
> process, but I'm not sure if it's the best idea from the point of view
> of maintainability because a package update could eliminate that change.

I believe the correct approach is to add one of the limitXXXX= directives
to the systemd unit.  See systemd.exec(5) for details.  Searching for
the word "limit" gets you to the correct section.

[toc] | [prev] | [next] | [standalone]

#177560

[Multipart message — attachments visible in raw view] — view raw

Hi, Greg.

On 08/02/17 10:20, Greg Wooledge wrote:

>> The process starts as a service, so it does not require a shell:

>> I had thought that I could add something to the script that starts the
>> process, but I'm not sure if it's the best idea from the point of view
>> of maintainability because a package update could eliminate that change.

> I believe the correct approach is to add one of the limitXXXX= directives
> to the systemd unit.  See systemd.exec(5) for details.  Searching for
> the word "limit" gets you to the correct section.

Very interesting. Thanks for the reference! I see that in this case the
directive to use is LimitNOFILE=<something>. Although I did not find the
syntax (for example, LimitNOFILE=soft:hard).

In this case, it seems that the service file for systemd is created
dynamically. Or I'm wrong?

--------------------------------------------------------------------
root@conference:~# find / -name jitsi-videobridge.service
/sys/fs/cgroup/systemd/system.slice/jitsi-videobridge.service
/run/systemd/generator.late/jitsi-videobridge.service
/run/systemd/generator.late/runlevel5.target.wants/jitsi-videobridge.service
/run/systemd/generator.late/runlevel4.target.wants/jitsi-videobridge.service
/run/systemd/generator.late/runlevel3.target.wants/jitsi-videobridge.service
/run/systemd/generator.late/runlevel2.target.wants/jitsi-videobridge.service
--------------------------------------------------------------------


Thanks for your reply.

Kind regards,
Daniel

[toc] | [prev] | [next] | [standalone]

#177565

Daniel Bareiro <daniel-listas@gmx.net> wrote:
> On 08/02/17 10:20, Greg Wooledge wrote:

>>> The process starts as a service, so it does not require a shell:

>>> I had thought that I could add something to the script that starts the
>>> process, but I'm not sure if it's the best idea from the point of view
>>> of maintainability because a package update could eliminate that change.

>> I believe the correct approach is to add one of the limitXXXX= directives
>> to the systemd unit.  See systemd.exec(5) for details.  Searching for
>> the word "limit" gets you to the correct section.

> Very interesting. Thanks for the reference! I see that in this case the
> directive to use is LimitNOFILE=<something>. Although I did not find the
> syntax (for example, LimitNOFILE=soft:hard).

The documentation is in systemd.exec(5).

> In this case, it seems that the service file for systemd is created
> dynamically. Or I'm wrong?

> --------------------------------------------------------------------
> root@conference:~# find / -name jitsi-videobridge.service
> /sys/fs/cgroup/systemd/system.slice/jitsi-videobridge.service
> /run/systemd/generator.late/jitsi-videobridge.service
> /run/systemd/generator.late/runlevel5.target.wants/jitsi-videobridge.service
> /run/systemd/generator.late/runlevel4.target.wants/jitsi-videobridge.service
> /run/systemd/generator.late/runlevel3.target.wants/jitsi-videobridge.service
> /run/systemd/generator.late/runlevel2.target.wants/jitsi-videobridge.service
> --------------------------------------------------------------------

> Thanks for your reply.

You can also generate override files for dynamically generated units by
creating /etc/systemd/system/jitsi-videobridge.service.d/configname.conf

"configname" can be whatever you want.

In this file you then put

,----
| [Service]
| LimitNOFILE=65536
`----

and do a "systemctl daemon-reload".

If you now "systemctl cat jitsi-videobridge.service" you should get the
output of the generated file and your appended override config.

Grüße,
Sven

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#177575

[Multipart message — attachments visible in raw view] — view raw

Hi, Sven.

On 08/02/17 14:37, Sven Hartge wrote:

>> In this case, it seems that the service file for systemd is created
>> dynamically. Or I'm wrong?
>>
>> --------------------------------------------------------------------
>> root@conference:~# find / -name jitsi-videobridge.service
>> /sys/fs/cgroup/systemd/system.slice/jitsi-videobridge.service
>> /run/systemd/generator.late/jitsi-videobridge.service
>> /run/systemd/generator.late/runlevel5.target.wants/jitsi-videobridge.service
>> /run/systemd/generator.late/runlevel4.target.wants/jitsi-videobridge.service
>> /run/systemd/generator.late/runlevel3.target.wants/jitsi-videobridge.service
>> /run/systemd/generator.late/runlevel2.target.wants/jitsi-videobridge.service
>> --------------------------------------------------------------------

> You can also generate override files for dynamically generated units by
> creating /etc/systemd/system/jitsi-videobridge.service.d/configname.conf
> 
> "configname" can be whatever you want.
> 
> In this file you then put
> 
> ,----
> | [Service]
> | LimitNOFILE=65536
> `----
> 
> and do a "systemctl daemon-reload".
> 
> If you now "systemctl cat jitsi-videobridge.service" you should get the
> output of the generated file and your appended override config.

Great! That worked! It seems that the only value specified in
LimitNOFILE applies to both the soft and hard limit.

Thank you very much for your reply.

Kind regards,
Daniel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web