Cron.file is not working - 'NoneType' object has no attribute 'startswith'

[luizsilva]

After updating salt to 2014.1 (from 0.17) the cron state is not working anymore.

I was under the impression it was because the crontab for user root was empty but even with something on it (in this case a comment) the state still fails.

[INFO ] Running state [salt://cron/configs/ops_root.txt] at time 16:47:40.498803
[INFO ] Executing state cron.file for salt://cron/configs/ops_root.txt
[INFO ] Executing command 'crontab -l -u root' in directory '/root'
[INFO ] stdout: #

[ERROR ] Unable to manage file: 'NoneType' object has no attribute 'startswith'
[INFO ] Completed state [salt://cron/configs/ops_root.txt] at time 16:47:40.521779

This is an Arch Linux box ( 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux) running as a container on proxmox.

[basepi]

Strange, thanks for the report. We'll look into this.

[dmyerscough]

@luizsilva can you show me the cron state you are using.

[luizsilva]

@dmyerscough :

{% if grains['class'] != 'dev' %}
root_crontab:
cron:
- file
- name: salt://cron/configs/{{ grains['class'] }}_root.txt
- template: jinja
- user: root
- require:
- pkg: cronie
{% endif %}

cronie:
pkg:
- installed
require:
- pkg.removed: dcron

service:
- running
- enable: true
- require:
- pkg: cronie

[luizsilva]

Sorry, clicked "close" by mistake.

[dmyerscough]

Thank you @luizsilva I will try get to this at the weekend.

[defunctzombie]

I am seeing a similar failure in cron.file after upgrading to 2014.1.0 (from 0.17).

My cron state is a bit simpler:

crontab:
  cron.file:
    - name: salt://files/crontab
    - user: root

Salt fails with

----------
          ID: crontab
    Function: cron.file
        Name: salt://files/crontab
      Result: False
     Comment: Source file salt://files/crontab not found
     Changes:

I am not using templates like OP is, but these issue may be related.

[JensRantil]

I am too seeing the "Source file salt://files/crontab not found" issue after upgrading to 2014.1.0.

[fsniper]

Seems like,

on def cache_loc(self, path, saltenv='base', env=None) at salt/fileclient.py, if saltenv is None

    dest = os.path.join(self.opts['cachedir'],
                        'files',
                        saltenv,
                        path)

code block threws

  >>> os.path.join("a", None, "b")
  Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/usr/lib/python2.7/posixpath.py", line 75, in join
     if b.startswith('/'):
     AttributeError: 'NoneType' object has no attribute 'startswith'

(it's strange that it is None because the prototype shows a default value for the param)

[fsniper]

So python 2.7 has the tendency to use None value if you intensionally pass a None value to a parameter with a default.

   >>> def test(a, b="Def"):
   ...     print a
   ...     print b
   ... 
   .>>> test("a","b")
   a
   b
   .>>> test("a")
   a
   Def
   .>>> test("a",None)
   a
   None

[fsniper]

For a workaround one may use env: prod in the cron.file state.

[JensRantil]

For a workaround one may use env: prod in the cron.file state.

I can confirm that the workaround worked for me.

[basepi]

Is this issue fixed with the above commits?

[defunctzombie]

I don't see the nonetype issue, but I still get the source file not found
issue.
On Mar 11, 2014 4:43 PM, "Colton Myers" notifications@github.com wrote:

Is this issue fixed with the above commits?

Reply to this email directly or view it on GitHubhttps://github.com//issues/10656#issuecomment-37347313
.

[dmyerscough]

@defunctzombie can you view your crontab file on the master from the client? Can you verify this with cp.list_master

sudo salt-call cp.list_master

[defunctzombie]

local:
    - ...
    - files/crontab

I get that result back with the file shown in the list. Guessing that is as expected?

[defunctzombie]

So after applying the patch I think the issue with file not found goes away (when I run salt-call locally on the machine it works) but when I do state.highstate from the master it doesn't until I restart the minion to use the patched version. So it seems the patch did help.

[basepi]

So the source file not found issue is now fixed as well?

[defunctzombie]

@basepi seems to be

[basepi]

Awesome!