I’m guessing it’s just a bad init script in some form.
Tried the service module?
Yes the service module does not work with dkim-filter, it looks like this:
sudo ansible test -m service -a “name=dkim-filter state=restarted”
example1.tld | FAILED >> {
“changed”: false,
“failed”: true,
“module”: “service”,
“msg”: “failed determining the current service state => state stays unchanged”
}
Yeah, it doesn’t support “status” most likely.
It I want to upgrade the service module to take a pattern to look for the process in PS if supplied, like "pattern=“dkim-filter” as an argument.
This may help with bad init scripts more so than some other things or trying to fix them
Somebody send me a patch or I’ll see about doing it later for 0.7.
I changed dkim-filters init script to support “status” and am now able to restart with the service module,
but it still does not explain why the program is not started when using the “command” module
I think your “pattern” idea is good, another way could be to have a “force=yes” or “ignorestatus=yes” so we can ignore status.
unfortunately im not fluent in python so i’ll just step back and allow others to do the patching 
I changed dkim-filters init script to support “status” and am now able to restart with the service module,
but it still does not explain why the program is not started when using the “command” module
Good deal. I suspect something is not liking that it’s tty is going away, though I have not looked at the init script in question.
Bad init scripts are pretty much legion.
I don’t think it’s anything to do with the command module, but I also don’t know anything about dkim-filter.
I think your “pattern” idea is good, another way could be to have a “force=yes” or “ignorestatus=yes” so we can ignore status.
unfortunately im not fluent in python so i’ll just step back and allow others to do the patching
The pattern thing is what Puppet did, and I’m perfectly happy to take good ideas from there. It wouldn’t be too difficult.
Needs to be 0.7 though.