zookeeper-el7-rpm icon indicating copy to clipboard operation
zookeeper-el7-rpm copied to clipboard

Published 20 hours ago • verified publisher icon id

Path to Java should not be hardcoded

Open akamensky opened this issue 5 years ago • 3 comments

Offending lines: https://github.com/id/zookeeper-el7-rpm/blob/e2d402f62a27c4caba49cd19e4a145ef41b6e198/zookeeper.service#L9 https://github.com/id/zookeeper-el7-rpm/blob/e2d402f62a27c4caba49cd19e4a145ef41b6e198/zkcli#L6

Java does not always come from system packages and thus frequently is installed outside of $PATH, and also not in /bin/

Instead the .service file should use zkServer.sh that comes with binary distribution of zookeeper, which will utilize provided $JAVA_HOME, that in turn can be placed in /etc/sysconfig/zookeeper and after installation.

akamensky avatar Sep 13 '19 02:09 akamensky

I prefer to not use startup scripts designed to work with init.d together with systemd. The problem you are talking about can be easily solved the same way as it is solved in zkServer.sh.

id avatar Sep 13 '19 07:09 id

Don't need to use init.d style scripts for this. I.e. can work around this same way as package from bigtop does -- they have wrapper scripts that will source /etc/default/zookeeper and will then call to zkServer.sh (or another script). I on my side already implemented those scripts and then replaced ExecStart (and also added missing ExecStop JFYI) to call to those scripts instead.

akamensky avatar Sep 13 '19 08:09 akamensky

zkServer.sh is exactly init.d style script. Why invent workaround? All zkServer.sh does is calculates which flags to pass to JVM and old-style process management via pidfile. All variables are configured in /etc/sysconfig/zookeeper, everything else you can leave to systemd. Calling zkServer.sh to stop the process is less reliable than letting systemd do it.

id avatar Sep 13 '19 08:09 id