Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-4566: multiple changes $(dirname "$0.. to $(dirname "$(readlink -f "$0.. #17326

Closed
wants to merge 2 commits into from

Conversation

itfromblighty
Copy link

@itfromblighty itfromblighty commented Sep 30, 2024

This PR allows people to symlink to e.g. /opt/kafka/bin/kafka-console-consumer.sh and when they execute the script it does not fail due to exec $(dirname $0.. when the directory of the symlink is not the same i.e. the symlink is in a separate directory so that binaries don't have to be cloned when a separate directory is used for e.g. configuration. This was raised as a bug in 2016 and was never fixed since the original proposal was not platform agnostic (MacOS vs Linux) and further proposals were heavy-handed. However, "readlink -f" is platform portable (across MacOS and Linux i.e. official docker container) and neatly solves the problem with symlinking to /opt/kafka/bin scripts.
This is my original work and I license this work to the project under the project's open source license.

@edoardocomar
Copy link
Contributor

@itfromblighty if I search the repo for "$(dirname $0 I still get some hits, can you please take another look ?

…/also applies to config and logs - as these must be able to be found without necessarily being copied to-relative-to the symlink
@itfromblighty
Copy link
Author

itfromblighty commented Oct 1, 2024

@edoardocomar, yes, in several places there are/is basedir=$(dirname $0) for example relative directory to config - I thought the purpose of this 'bug' was to continue to allow the user/admin to use (e.g.) config relative to where they'd symlink-ed the kafka .sh script from, as opposed to locking-in all subsequent 'paths' into the kafka/bin directory?.. However, on second thoughts, I see that every time the base_dir is used, it's only when an environment variable isn't defined. So I think it makes sense to apply this readlink logic to everything (now). There are (were) (still) matches for "$(dirname $0)" yes:

bin/connect-mirror-maker.sh [candidate#1]
bin/zookeeper-server-start.sh [candidate#2]
bin/connect-standalone.sh [candidate#3]
bin/connect-distributed.sh [candidate#4]
bin/kafka-run-class.sh [candidate#5]
bin/kafka-server-start.sh [candidate#6]
vagrant/package-base-box.sh
vagrant/aws/aws-init.sh
tests/bootstrap-test-env.sh
jmh-benchmarks/jmh.sh
examples/bin/java-producer-consumer-demo.sh [candidate#7]
examples/bin/exactly-once-demo.sh [candidate#8]
raft/bin/test-kraft-server-start.sh [candidate#9]

However, since this 'bug' was for "Kafka bins", I'd limited the change/s to bin/.sh only. I've updated candidates 1 through 5 as-per my adjusted understanding at the top of this comment, and updated candidates 7 through 9 as while these are outside the kafka/bin directory, they look, smell, and feel the same as the majority of the rest of the kafka/bin/.sh scripts. I've also taken the liberty to surround ALL instances of $base_dir with double-quotes (except when they're already in double-quotes)

@itfromblighty
Copy link
Author

@mumrah, hi. I see you're a committer on this project. Is there anything I can do, to help with getting this PR merged with trunk?

@cmccabe
Copy link
Contributor

cmccabe commented Oct 3, 2024

readlink -f doesn't exist on Macs prior to macOS 12.3. More details here:

https://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac

I don't know what our policy is for older MacOS versions, but it seems too soon to drop support for 2022-era MacOS.

@mumrah
Copy link
Contributor

mumrah commented Oct 4, 2024

I don't think we have official supported versions of Mac or Linux, but I agree we should not break a version of MacOS that is still supported. It looks like Mac OS 12 will be EoL later this year, so maybe we can make this change in a future release like 4.1.

I'm going to close this PR for now. @itfromblighty I've updated the ticket with a fix version of 4.1, so we can re-open this PR once we're closer to that release. Thanks for the fix btw!

@mumrah mumrah closed this Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants