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

Puppet Cron Resource Overwrites Crontab File Under Certain Situations

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 3.4.3, PUP 3.6.2
    • Fix Version/s: PUP 4.0.0
    • Component/s: None
    • Labels:
    • Template:

      Description

      In the case where a crontab file has invalid entries the cron resource ends up overwriting the whole file with just the resources puppet knows about and removes any manually entered crontab entries even if they were valid.

      On a fresh system I have the following crontab setup provided by puppet:

      [root@master323-centos ~]# crontab -l
      # HEADER: This file was autogenerated at 2014-05-02 17:31:32 +0000 by puppet.
      # HEADER: While it can still be managed manually, it is definitely not recommended.
      # HEADER: Note particularly that the comments starting with 'Puppet Name' should
      # HEADER: not be deleted, as doing so could cause duplicate cron jobs.
      # Puppet Name: pe-mcollective-metadata
      0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
      # Puppet Name: pe-puppet-console-prune-task
      * 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
      

      I then use crontab -e to add a new entry:

      [root@master323-centos ~]# crontab -e
      crontab: installing new crontab
      [root@master323-centos ~]# crontab -l
      # HEADER: This file was autogenerated at 2014-05-02 17:31:32 +0000 by puppet.
      # HEADER: While it can still be managed manually, it is definitely not recommended.
      # HEADER: Note particularly that the comments starting with 'Puppet Name' should
      # HEADER: not be deleted, as doing so could cause duplicate cron jobs.
      # Puppet Name: pe-mcollective-metadata
      0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
      # Puppet Name: pe-puppet-console-prune-task
      * 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
      0,15,30,45 * * * * /opt/puppet/bin/facter -p
      

      Now I add an invalid entry by editing the file directly:

      [root@master323-centos ~]# vim /var/spool/cron/root
      [root@master323-centos ~]# crontab -l
      # HEADER: This file was autogenerated at 2014-05-22 21:32:18 +0000 by puppet.
      # HEADER: While it can still be managed manually, it is definitely not recommended.
      # HEADER: Note particularly that the comments starting with 'Puppet Name' should
      # HEADER: not be deleted, as doing so could cause duplicate cron jobs.
      # Puppet Name: pe-mcollective-metadata
      0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
      # Puppet Name: pe-puppet-console-prune-task
      * 1 * * * /opt/puppet/bin/rake -f /opt/puppet/share/puppet-dashboard/Rakefile RAILS_ENV=production reports:prune reports:prune:failed upto=30 unit=day > /dev/null
      0,15,30,45 * * * * /opt/puppet/bin/facter -p
      safdljasdflkja
      

      When I run puppet it overwrite the file and I lose the legitimate entry that I had entered with crontab -e:

      [root@master323-centos ~]# puppet agent -t
      Info: Retrieving plugin
      Info: Loading facts in ...
      ...
      Info: Caching catalog for master323-centos
      Info: Applying configuration version '1400794238'
      Error: Could not prefetch cron provider 'crontab': Could not parse line "safdljasdflkja" at root:7
      Notice: /Stage[main]/Pe_mcollective::Server/Cron[pe-mcollective-metadata]/ensure: created
      Notice: /Stage[main]/Pe_console_prune/Cron[pe-puppet-console-prune-task]/ensure: created
      Notice: Finished catalog run in 14.11 seconds
      

      I'm not sure of the ideal behavior but I see two options that could make it better:
      1. Backup the crontab file to the filebucket so atleast if it gets wiped out I can just restore to the previous version.
      2. Fail completely and do not manage the crontab entries if the file is in an invalid state.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              nick.walker Nick Walker
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support