Jira (PUP-6861) [regression] Mount options not idempotent
Title: Message Title Thomas Kornack commented on PUP-6861 Re: [regression] Mount options not idempotent As Branan Riley suggested in his answer to PUP-6457 I'll gladly add some examples where the puppet agent remounts a share at every run and where fstab options and output of mount differ. All the cases did not occur prior to the update to puppet agent v1.8.0: 1st Example: (2 Hosts) Distro: Ubuntu 12.04.05 LTS FS type, issue: nfs, remout with every agent run fstab: some.ip.add.ress:/home/some.user /home/some.user nfs _netdev,vers=3,bg,soft,intr,retry=5 0 0 mtab: some.ip.add.ress:/home/some.user /home/some.user nfs rw,vers=3,bg,soft,intr,retry=5 0 0 2nd example: Distro: Ubuntu 14.04.05 LTS FS type, issue: tmpfs, remout with every agent run fstab: /dev/shm /var/lib/amavis/tmp tmpfs defaults,size=250m,mode=770,uid=amavis,gid=amavis 0 0 mtab:
Jira (PUP-6457) Mount resources could handle invalid options better
Title: Message Title Thomas Kornack commented on PUP-6457 Re: Mount resources could handle invalid options better As Branan Riley suggested in his answer to PUP-6457 I'll gladly add some examples where the puppet agent remounts a share at every run and where fstab options and output of mount differ. All the cases did not occur prior to the update to puppet agent v1.8.0: 1st Example: (2 Hosts) Distro: Ubuntu 12.04.05 LTS FS type, issue: nfs, remout with every agent run fstab: some.ip.add.ress:/home/some.user /home/some.user nfs _netdev,vers=3,bg,soft,intr,retry=5 0 0 mtab: some.ip.add.ress:/home/some.user /home/some.user nfs rw,vers=3,bg,soft,intr,retry=5 0 0 2nd example: Distro: Ubuntu 14.04.05 LTS FS type, issue: tmpfs, remout with every agent run fstab: /dev/shm /var/lib/amavis/tmp tmpfs defaults,size=250m,mode=770,uid=amavis,gid=amavis 0 0 mtab:
Jira (PUP-6457) Mount resources could handle invalid options better
Title: Message Title Thomas Kornack commented on PUP-6457 Re: Mount resources could handle invalid options better I have a similar issue since the installation of puppet-agent v1.8.0 yesterday which might also be related to the changes: The mount of a ram disk gets executed at every puppet agent run. The Logfile reads: /Nov 3 13:55:32 host007 puppet-agent[20688]: (/Stage[main]/Mailserver::Amavis/Mount[/var/lib/amavis/tmp]/options) options changed 'defaults,size=250m,mode=770,uid=amavis,gid=amavis' to 'defaults,size=250m,mode=770,uid=amavis,gid=amavis' I think I found the reason for the problem: Mount option and output of 'mount' differ: The given options for the mount object are those found in the logs (see above). Mount reports: root@host007:/var/log/puppet# mount |grep amavis /run/shm on /var/lib/amavis/tmp type tmpfs (rw,size=250m,mode=770,uid=109,gid=115) Mount options use user name and group name while 'mount outputs' uid and gid. I cannot change the mount options to use ids because uid and gid differ on different hosts. Is there an easier solution than to write own facts to read the right uid/gid? Add Comment
Jira (PUP-3345) Puppet Master Memory Leak
Title: Message Title Thomas Kornack commented on an issue Re: Puppet Master Memory Leak Im running two puppetmasters on KVM based virtual hosts. OS is Ubuntu 12.05 LTS. Puppetmasters and clients (~30) all use puppet v3.7.2. I'm also using directory environments. No puppetdb in use. I can confirm the behavior described here: Memory usage increases until the host becomes inaccessible. It also happens when only one client is bound to the puppetmaster using only one module with one empty puppet class. With the setting 'environment_timeout = unlimited' the memory usage does not increase or the increase is below measuring limit. I have knowledge of two other puppetmasters running on Ubuntu 12.05 LTS on another site: Directory environments are not used and the memory problems don't occur. Add Comment Puppet / PUP-3345 Puppet Master Memory Leak Starting with 3.7, the Puppet master process will allocate more and more memory until it is killed by the OOM process. This occurs in about 24 hours in our environment. The behaviour occurs in both Rack and WEBRick configurations. In the Rack configuration the four Rack processes will grow until killed. In WEBRick configuration the one puppet maste... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
