Hi @bernardn! I'm liking this. I'll think about this a little bit more and see if I have some feedback.

It looks like you've made a decision to leave the logging directory to be /var/log/go-agent and not change it to SERVICE_NAME, right? I think that could cause two agents to share one log file. That's because /etc/go/log4j.properties has names such as go-agent.log hard-coded in them, and won't be affected by SERVICE_NAME. Let me know what you think about that.

That's the only feedback that comes to mind right now. I'll look at this in a little more detail and see if I have anything else to ask you about.

Hi @arvindsv ! Thanks for reviewing. As long as other log files are going to be written there, it would be better, you're right, do differenciate the directory itself rather than the log file specified in the init script. I'll make this change and push it.
Because I wanted to perform the least possible changes in original code, I adopted the approach you can see in this pull request. Otherwise, I would have more deeply modified the script in order not to use the /usr/share/go-agent symlink, whose sole purpose is to get the right process. What is your opinion about this ?

Because I wanted to perform the least possible changes in original code, I adopted the approach you can see in this pull request. Otherwise, I would have more deeply modified the script in order not to use the /usr/share/go-agent symlink, whose sole purpose is to get the right process. What is your opinion about this ?

I think the approach you have taken is what I'd have done, at this point. Changing it to not use /usr/share/go-agent might have an impact on the installers, which install into that location. However, we can definitely talk about the deeper change, and see if it's something that should be done.

Was your idea to change how the pkill and pgrep around here work? Maybe adding a -Dservice.name=${SERVICE_NAME} and pkill using that?

Probably a question to @arikagoyal. When this change gets in, because of the change to installers/agent/release/default.cruise-agent, an agent upgrade will ask a question to the user who is upgrading it. It looks like this:

Is this acceptable? I feel it is because of two reasons:

1. An agent upgrade almost never happens, since it is automatically done by the Go Server and Agent bootstrapper.
2. It is possible to provide an option to prevent this prompt. It'll look like this, then:

I can accept this change, if you agree. With apologies to bernardn for me forgetting about this and getting caught up with other things.

Talked about this briefly with @arikagoyal and @jyotisingh. I think this can be merged, since there is an option to make it choose old or new configs, and the fact that this is not an operation done often (agent upgrade using DEB and RPM). During an RPM upgrade, this happens:

RPM has chosen the "use old config" option by default, and has written the new config to a .rpmnew file.

Both these behaviors are standard for DEB and RPM. So, I am accepting this.

Verified on 15.1.0(1643-d2aa1fdc52e09e)