Hey Pierre. On Tue, 2022-12-06 at 23:08 +0100, Pierre Gruet wrote: > Thanks for the bug report (and the follow-up precisions you sent)! > > Yet I fail to reproduce it on testing. I installed zookeeper and > zookeeperd on testing, then ran > > $ /usr/share/zookeeper/bin/zkCli.sh > specifying nothing about the classpath (it is already handled in the > MANIFEST.MF file of the zookeeper jar), and I could enter commands > (though with no prompt, as you say).
When you've started your zookeeper (I assume you also use the sysvinit script, respectively the virtual systemd unit generated from that?), what does your process' command line show, e.g.: # ps ax | grep org.apache.zookeeper.server.quorum.QuorumPeerMain 3156 ? Sl 167:08 /usr/bin/java -cp /etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-log4j12.jar:/usr/share/java/log4j-1.2.jar -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=true -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg Especially, which CLASSPATH (seems to be the -cp)? Is your test system clustered (i.e. more than one ZK node?)? > (However, I also get the hanging issue if I do not install > zookeeperd.) Well I guess that's clear, cause then nothing would have started zookeeper?! > I guess there is some difference in the versions of the dependencies > between stable and testing, as you underline that the dependencies > come > from stable. That would be quite surprising, IMO,.. cause the issue seems to be quite clearly the missing CLASSPATH stuff. I mean if there would be some other package, that is used to start the java process... and that other package would have a different version and thus be incompatible, I could imagine this. But it seems as if zookeeper's sysvinit script does all on it's own and simply execute java in the end. So it's hard to imagine, that something interferes, and somehow breaks the CLASSPATH there?! > Concerning the SLF4J warning: in the past I already stumbled upon > this > and visited the URI > https://www.slf4j.org/codes.html#StaticLoggerBinder > which is in the warning message. Yeah, also stumbled over that via the error message. > Because of the last paragraph in the > relevant section therein, I was unsure I should choose a SLF4J > binding > as this would impose my choice to the end user. What do you think? Well since that two infamous security holes, log4j has a somewhat damaged reputation ;-) ... but apart from that I think this would make the most sense here. As I've said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025012#20 : /usr/share/java/slf4j-log4j12.jar wasn't enough for me and I needed to add /usr/share/java/log4j-1.2.jar to the CLASSPATH instead, in order to get output to /var/log/zookeeper > Finally, as: > - I think there is a mismatch somewhere in the versions of the > dependencies between stable and testing; > - I cannot reproduce on a system with dependencies fetched from > testing > only, > I would tend to discuss only the SLF4J issue and ignore the rest. > > Please tell me what you think, I think we should look into both, and at best split things apart. I mean I can try to reproduce the whole thing on a sid or testing only systemd an see whether it still fails to start, but right now I'd be quite surprised why it wouldn't start because of that... and even *if* that would be the reason, then bullseye to bookwork upgrades need to be supported, and therefore the package (zookeeper) would need to have correct versioned dependencies (*if* it's because of a incompatible version of some dependency). Thanks, Chris.
