Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6635

An exec resource specifying a user will not inherit that user's limits from /etc/security/limits.conf



    • Type: Bug
    • Status: Accepted
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Environment:

      RHEL 6.7 running 2016.1.1 agent
      Reproduced internally on CentOS 6.6 with 2016.2.1 agent

    • Template:
    • Agent OS:
      RHEL 6 (i386, x86_64)
    • Master OS:
      RHEL 6 (x86_64)
    • Team:
      Night's Watch


      In a case where limits (such as no of file handles allowed etc.) have been set for a user on a system using either /etc/security/limits.conf or a separate file under /etc/security/limits.d/, when an exec resource is run as this user, these limits are ignored and defaults are used.

      This can be easily reproduced by creating a user (oracle in my tests and in customer ticket) and setting nofile hard and soft limits for this user in either /etc/security/limits.conf or by creating a file under /etc/security/limits.d/ with the appropriate prefix and username.

      [root@pe-201621-agent vagrant]# cat /etc/security/limits.conf | grep oracle
      oracle           soft    nofile          4096
      oracle           hard    nofile          63536
      [root@pe-201621-agent vagrant]#

      Running a simple script to print the limits to the console as user oracle will print the values as defined:

      [oracle@pe-201621-agent vagrant]$ cat /tmp/test_ulimit.sh
      echo "Hard:"
      /bin/bash -c 'ulimit -Hn'
      echo "Soft:"
      /bin/bash -c 'ulimit -Sn'
      [oracle@pe-201621-agent vagrant]$ /tmp/test_ulimit.sh
      [oracle@pe-201621-agent vagrant]$

      However, when this same script is called using puppet code, running puppet as root, different values are noted:

      [root@pe-201621-agent vagrant]# cat test_ulimit.pp
      include test_ulimit
      class test_ulimit {
        exec { "test_ulimit":
          provider => "shell",
          user => "oracle",
          path => "/tmp",
          command => "test_ulimit.sh",
          logoutput => "true"

      [root@pe-201621-agent vagrant]# puppet apply test_ulimit.pp
      Notice: Compiled catalog for pe-201621-agent.puppetdebug.vlan in environment production in 0.07 seconds
      Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Hard:
      Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 4096
      Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: Soft:
      Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: 1024
      Notice: /Stage[main]/Test_ulimit/Exec[test_ulimit]/returns: executed successfully
      Notice: Applied catalog in 0.06 seconds
      [root@pe-201621-agent vagrant]#

      I suspect that the script called by the exec resource is actually inheriting the limit values from the puppet process, while it does actually run as the user specified in the exec resource in puppet code.

      The issue is that the customer is using this exec to kick off processes which interact with an oracle database as the oracle user, and needs the increased number of open file descriptors.

      Is this a natural by-product of using an exec resource, or is it a bug? Is there a way to resolve this either in the puppet code written by the customer in the exec resource or in the product itself?

      If I have linked to the wrong scrum team, please re-assign.




            stefan.pijnappels Stefan Pijnappels
            0 Vote for this issue
            6 Start watching this issue



                Zendesk Support