Bug#1025012: zookeeper: starts but is completely unusable

[Pierre Gruet]

Hello Chris,

Le 06/12/2022 à 23:33, Christoph Anton Mitterer a écrit :

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)?

Yes this is the -cp argument.

I got

4558 ? Sl 0:02 /usr/bin/java -cp /etc/zookeeper/conf:/usr/share/java/zookeeper.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 Could you please send the contents of your /etc/zookeeper/conf/environment? I think this is where the classpath is set, and we might have caught a wrong bullseye-to-bookworm upgrade case here.

Is your test system clustered (i.e. more than one ZK node?)?

I humbly admit I cannot answer as I am not a zookeeper user... but if you tell me where to look I might tell.

(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?!

Sure :) I was stating this because here is the only way I could get the same kind of error as yours.

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?!

As you suggest (see my request above), we don't have the same classpath and this might be because you already had zookeeper installed from old bullseye package and then upgraded. I think /etc/zookeeper/conf contents is set up by update-alternatives and maybe something is not working well in our post-install treatments in the case of an upgrade from an already-installed zookeeper.

[...]

  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

You're right, this makes sense then.

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).

That's right, seeing your classpath contents in the top part of your last mail makes me think there is something wrong in the upgrade process and this should be addressed -- let's see this. I would be interested in your /etc/zookeeper/conf/environment contents, as I said above.

Thanks,
Chris.

Thanks also to you,

--
Pierre

OpenPGP_signature
Description: OpenPGP digital signature