Ansible-lint causes massive amount of debug logging to syslog

I’ve just upgraded ansible-core and ansible-lint to 2.15.4 and 6.19.0 respectively, and now when I run

$ ansible-lint --offline site.yml

I get a large amount (megabytes) of data to syslog on this host, of the form:

Sep 17 00:36:00 ansible Invoked with path={{ item }} owner=root group=adm mode=0640 recurse=False force=False follow=True modification_time_format=%Y%m%d%H%M.%S access_time_format=%Y%m%d%H%M.%S unsafe_writes=False state=None _original_basename=None _diff_peek=None src=None modification_time=None access_time=None seuser=None serole=None selevel=None setype=None attributes=None

I assume this is from when ansible-lint calls:

/bin/python /srv/venv/ansible/bin/ansible-playbook -i localhost, --syntax-check site.yml

…though I have been unable to replicate that behaviour when calling ansible-playbook myself.

This logging is not very useful to me. Is there a way to disable it when invoking ansible-lint? I am just calling that from the command line at the moment, not CI or commit hook or anything.

I do not get that sort of logging during my normal use of ansible-playbook; it only happens when I call ansible-lint, so I don’t think it’s anything in my ansible.cfg file.



Hello Andy, I’m gonna keep track of this thread because I also have a problem with ansible-linter on vscode + WSL (Yeah, my job’s laptop runs windows11, so I had installed Ubuntu20.04 on WSL). More precisely, what I noticed is that when I have several projects opened, ansible-linter eats most of WSL’s resources (RAM & CPU). I dunno if that has any relationship with the problem you’re exposing in your post, but I think is worth a shot to investigate further to see if yours and mine have the same root cause. I’ll get back to you if I get to any conclusion.


1 Like

These entries are created when ansible runs a Python module on that machine. (

These entries should not come from --syntax-check since that should not execute any modules.

Maybe you do something else that uses ansible-playbook to run modules on your machine (localhost)? Maybe molecule tests?


I am only seeing this when I run ansible-lint on my controller machine against my playbook site,yml. I do not see it on the controller or on any managed host when I run the playbook with ansible-playbook. So I haven’t taken any steps to cause such logging in the playbook and am confused as to why it’s happening only with lint.

I ran strace -ff ansible-lint … and the only thing that was executed (execve) that I thought could plausibly cause it was the ansible-playbook -i localhost, --syntax-check thing. But I wouldn’t be surprised if I was mistaken and like I say, I haven’t been able to replicate this outside of running ansible-lint.

It only happens when running ansible-lint. I don’t even know what molecule is. :grinning:
It’s also only since upgrading ansible-lint. I’ve been running lint for years and never seen this before.

Also please note that localhost isn’t in my playbook’s inventory, none of my plays target localhost and although the controller machine is one of the machines listed in the inventory, it is listed there under its real name, not localhost. That’s the other thing that made me think it was that --syntax-check command as that’s the only command I see ansible-lint calling and when it does, it specifies -i localhost,.

1 Like

While reading your reply I remembered that there is a new “feature” in ansible-lint that validates task parameters ( And instead of relying on ansible-doc to extract the officially supported module/action options, it does some fancy patching and code execution ( of the acutal module. Which will result in logging the module’s “parameters” to syslog.


(Since this happens inside the ansible-lint process you won’t see it with strace.)

1 Like

I see. It does not seem useful for it to do that without it being explicitly requested. Is there any way to disable the logging?

I suppose I could skip linting of args[module], or I could configure rsyslog to silently drop such messages…

1 Like

@DevTools is it possible to disable this behaviour?

1 Like

We could obviously do something but for this we would need a bug report that demonstrates the issue. So far I do not see our code as generating these syslog entries. Ansible-doc does not work the same way as running the modules.

Please make a simple example that reproduces the issue, minimal playbook, preferably using only core ansible modules. Demonstrate that stuff endsup on syslog.

The fact that syslogging happens with code outside our codebase makes it tricky to address.