Add param for systemd service options

[zipkid]

Allow configuring PrivateTmp in systemd service file
https://stackoverflow.com/questions/41702332/attachnotsupportedexception-when-trying-to-start-a-jfr-recording/47664741#47664741

[zipkid]

I have changed this PR to allow setting any systemd service option instead of adding a param per option.

[zipkid]

I changed rubocop.yaml and set 'TargetRubyVersion' to 2.2 but codeclimate doesn't seem to pick up that change.

[cliffano]

Hello @bstopp . Any chance of this PR getting merged?
I encounter many occurrences where the default TimeoutStopSec=4min is not enough, hence the SIGINT wouldn't make a difference anyway since AEM doesn't get a chance to gracefully stop.

[bstopp]

The PR only contains an update to remove the PrivateTmp service def. It still contains the TimeoutStopSec declaration here.

So this won't fix your issue @cliffano.

Let me look at this weekend and see we can get a full/arbitrary set of key/values.

[cliffano]

I was under the impression that the TimeoutStopSec could be redeclared again in the key value pairs and overwrites the default TimeoutStopSec=4min , and since systemd_service_options is a hash, the users would be able to inject anything.

Alternatively, can't the systemd_service_options defines a default hash that contains systemd_service_options: { 'TimeoutStopSec' => '4min', 'KillSignal' => 'SIGCONT', 'PrivateTmp' => true } ?

[bdhoine]

@bstopp @zipkid @cliffano can we revisit this PR? It would be nice if this go merged. As far as I can tell we need to tackle the last comment. I think it would be nice if the static config like TimeoutStopSec and KillSignal would be indeed replace by defining them in the systemd_service_options config hash.

[zipkid]

@bdhoine I will look at this next week.

[bstopp]

I'll probably close this in favor of #128. Release coming soon.

[bstopp]

@zipkid @bdhoine @cliffano Thanks for all the feedback and help with this. I had some issues trying to merge this change in, that's why i have a different branch with the updates. I'm also running into some issue with updating all the dev gem dependencies. Many of them have updates that require rewriting of large portions of the module, hence why not Gemfile version updates; look for those soon.