Non-informative "Too many functions declared in state 'file' in SLS"

[non7top]

This error message is non-informative at all. At very least it should report the ID where the issue happens and preferably the line in the file.

[Ch3LL]

@non7top can you explain how you are running into this specifically? Possibly a reproducable case?

I'm just wondering if there is more information in the debug output as well. Thanks

[non7top]

The offending snippet was like this which took me a while to identify. vim syntax highlighting helped as it colored - salt:// in white while normally attributes(or whatever it is) are cyan.
Obviously salt should have reported something like "ID /etc/file has errors: Too many functions declared in state: managed and salt:// can't be used together".

/etc/file:
  file.managed:
    - template: jinja
    - salt://webserver/files/etc_file
    - require_in:

[shallot]

I had a similar run-in with this error message, and it was caused by doing this:

apt-get update and upgrade:
  pkg.uptodate:
    - refresh

rather than this:

apt-get update and upgrade:
  pkg.uptodate:
    - refresh: True

This seems eminently detectable - surely the error handler can spell out which 'function' was extra, and point the user more clearly to the problem. For example, say "Too many functions declared in state X in Y: please choose only one out of: uptodate, refresh, ..."

Indeed, it could then also try to cross-reference the list of extra functions with the list of valid arguments to the state used, and pinpoint the error even more clearly. For example, "Too many functions declared in state X in Y: unknown function detected: 'refresh' - did you mean the boolean parameter to function uptodate?"

[Ch3LL]

Agreed I'll label this as a bug that we will need to get fixed up thanks :) Thanks for the particular examples that will help.

[ngeovanis]

I ran into this error message on a simple state shown below. The proximate cause turned-out to be using this:

    - mode:770

...instead of this:

    - mode: 770

IOW lack of " " between ":" and "7".

ossec-tar-file:
  file.managed:
{% if grains['os'] == 'Debian' %}
    - name: '/var/ossec/ossec-hids-agent_2.9.2.2154stretch_amd64.deb'
    - source:
      - salt://ossec/files/ossec-hids-agent_2.9.2.2154stretch_amd64.deb
{% elif grains['os'] == 'Ubuntu' %}
    - name: '/var/ossec/ossec-hids-agent_2.9.2-2154xenial_amd64.deb'
    - source:
      - salt://ossec/files/ossec-hids-agent_2.9.2-2154xenial_amd64.deb
{% endif %}    
    - user: root
    - group: ossec
    - mode: 770

[ngeovanis]

FYI my indenting has been lost in the state quoted above.....
Also should have mentioned that master is at 2016.11.3 and minion at 2015.8.8.

[marco-m]

Hello any news ?

[Ch3LL]

@marco-m no one is currently working on this issue due to other higher priority issues. Please feel free to take a stab at a fix for this particular use case

[ngeovanis]

As I mentioned on 10 November, my specific problem was fixed with a 1-character change: An additional space between the colon and the keyword, eg. "Mode: 770" instead of "Mode:770".

[emerichunter]

Hi,
I had the same message today for a similar problem. I was missing a space 'maker_start:""' instead of 'maker_start: ""'. This would be a nice addon. Glad I found this issue BTW, it was really helpfull.

[DimentR]

If after mode: not write space, appears this error.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[srkunze]

I found this issue being reproduced by this:

directories__absent:
  file.absent:
    - attachments
    - require:
      - state1
    - require_in:
      - state2

Fix:

directories__absent:
  file.absent:
    - name: attachments
    - require:
      - state1
    - require_in:
      - state2

[udf2457]

Bit depressing to see this bug still exists five years later. Its the world's most useless error message.

[Freddyp91]

Going to the minion and 'tail -f /var/log/minion ' helped me to determine what the issue was..It wasn't spaces at all for me but that i had forgot to add a file that file.managed was pointing to..

[theYaric]

Also got this error due to missing space.

- repl:'#\1'

This is pathetic. First, inability to implement RE parsing. Second, misleading error message. Even 'Something wrong. Error #123456' will be more beneficial to user. And the last, this shameful error exists for 6 years now.

I am speechless.

[whytewolf]

this should be fixed with the merge of #65212