Allow for tildes on exec path if they aren't the start of the path

[munkyshi]

We use tildes in install paths (/foo/bar/baz/group~value~id). This doesn't jive well with the current regex: https://github.com/palantir/go-java-launcher/blob/develop/launchlib/launcher.go#L110 when the provided JAVA_HOME is a subdirectory of that install path.

Request is to allow tildes if they aren't at the beginning of the path (AKA won't resolve to the home directory).

[markelliot]

This hasn’t been an issue to date. Why is it an issue now?

[munkyshi]

I don't remember the full context at this point, but I think it was because I was looking at Skylab managing deployd, which would then change the deployd java binary's (symlinked) exec path to have tildes in it.

Evidently we were able to get things off the ground without this PR, so we must have found a workaround -- probably by using an absolute path with symlink resolution? -- so probably good to close out here.

@jlong8 to sanity check my statement, since she's evidently hitting something related?

[munkyshi]

Caught up with some context, and seems like there was some sort of regression with the symlink resolution -- reopening to continue discussion, since it seems like it'd be nice to have this regardless of the situation?

[markelliot]

sorry, could you sketch out a dummy example of the directory tree?

[jlong8]

The new service home path in Skylab-managed deployd is something like /foo/bar/services/daemons~deployd~id, which is a symlink to /foo/bar/services/.<id>. Before Skylab-managed deployd, deployd home was /foo/bar/skylab/deployd.

Our workaround was that in a script to start deployd when it was stopped, we used pwd -P when getting the service home to avoid symlinks. Looks like this change was never made to our init.sh, so if deployd was most recently started with the init script, then the java home directory was invalid according to this blacklist and java services couldn't start. We can workaround this by editing the init.sh script, so this change isn't urgent.

[munkyshi]

EDIT: whoops, it looks like @jlong8 already posted a more concise writeup of what I had here.

Sure -- I'm not sure if it's safe to post the exact details / paths on external github, so changing some details around.

We run go-java-launcher from a dummy-service from the path ${INSTALL_HOME}/service/lib/jdk8/bin/java.

Previously, $INSTALL_HOME did not contain tildes, and we'd run it from /foo/bar/dummy-service/service/lib/jdk8/bin/java.

We're now using a platform management tool that installs dummy-service on a path with tildes, and the bash launcher that wraps environment variables evaluates $INSTALL_HOME (using $(dirname "$0")) as: /foo/bar/baz/management~dummy-service~123/, so the java binary path is now: /foo/bar/baz/management~dummy-service~123/service/lib/jdk8/bin/java.

There is a workaround -- /foo/bar/baz/management~dummy-service~123 is actually a symlink to /foo/bar/baz/.123, and we can use the absolute path /foo/bar/baz/.123/service/lib/jdk8/bin/java, which satisfies the execution path safety check.

We've been using this workaround, but it recently failed us. There's a PR to fix that, but it'd be nice if the go-java-launcher worked with the tildes in the first place.

Summary of relevant paths:

$ cd /foo/bar/baz
$ tree

management~dummy-service~123 -> .123
.123
.123/service/lib/jdk8/bin/java

[markelliot]

Ok, instead of running things with the fully resolved path, can we set the execution environment that pokes go-java-launcher to have a base directory, instead?