About keeping the environment untouched when calling the service module on Linux (PR #7552)

Archives Ansible Developer
1

Hello,

I am responding with reference to github PR #7552 on this list as requested by Michael Dehaan.

I wrote this small patch in order to allow passing environmental variables with the ‘environment:’ key in tasks calling the service module. I actually needed this for this init script: “http://bazaar.launchpad.net/~maria-captains/maria/5.5/view/head:/debian/mariadb-server-5.5.mysql.init”

As you can see, the only way to change “MYSQLD_STARTUP_TIMEOUT” is by passing it as an environmental variable. Unfortunately, this is never passed to the init scipt if the ‘service’ binary is used by the service module on Linux, because this binary strips the environment before calling the init script. So I added an option that would make the service module call the init script directly, leaving the environment passed by Ansible untouched. In other words, with this option, the environment is passed exactly as the Ansible wants it to be passed.
I would agree with Michael Dehaan that init script can be written better and e.g. source vars from “/etc/default/someservice” instead of using environmental variables, but this is out of a playbook writer’s control. It is up to the upstream team to fix this, if they want and when they have the time to fix it. One would say to patch the init script yourself and add it to the deployment. However, this is quite risky because an upgrade of the package that provides the original init script would override the patched version. So, would you reconsider merging this patch or do you think there is a better solution to this problem?

P.S. Do you really find it more convenient to discuss about a PR in a another mailing list? Aren’t the PR discussions on github meant for discussing about the PRs?

2

As this is the first script I’ve heard of working this way, have you considered taking the init script and replacing it with a modified version of your own, perhaps using the copy module?

" Aren’t the PR discussions on github meant for discussing about the PRs?"

They are not very inclusive, and I prefer wider discussion most of the time.

Further, I usually prefer discussion prior to code than having to reply to a code submission - and that saves efforts all around.

3

As I said, I find this quite risky because an upgrade of the package that provides the original init script would override the patched version. Also, if you google it, you can see several people asking about how to pass environment vars to startup scripts. That said, I could understand it if you still think this is corner case and Ansible should not help with this. Ok.