-
Notifications
You must be signed in to change notification settings - Fork 78
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
EXTRA_LAUNCH_ARGS are not honored #25
Comments
I use Kubernetes as well and spent a long time trying to figure this out. In the end, though, it appears that only the first argument is honored i.e., anything after the first whitespace character is being ignored. If I escape the whitespace however, it seems to work. This is the only app I have noticed that didn't work with quotes and required escaping spaces. (part of) my deployment: env:
- name: EXTRA_LAUNCH_ARGS
value: --listen\ --verbose |
Thank you for sharing this issue, and even bigger thanks for sharing your solution with the escaped spaces! From your findings, I suspect it is the way that the args are being parsed into the launch command. I don't use Kubernetes, but I will try to replicate and fix this by testing a few different parsing strategies. |
Same problem when dockerized deploying on my Unraid NAS. I'm also trying to deploy the source code (from "oobabooga/text-generation-webui") by docker-compose and it working well with env item "CLI_ARGS=--listen --api --xformers --verbose". |
Ya escaping the chars worked for me. Thanks for the tip! |
Another workaround is to pass a single quoted string as an argument:
The root cause of the problem is in
eval "extra_launch_args=($EXTRA_LAUNCH_ARGS)"
LAUNCHER=($@ $extra_launch_args)
eval "extra_launch_args=($EXTRA_LAUNCH_ARGS)"
LAUNCHER=($@ "${extra_launch_args[@]") |
@Artem-B - thank you for spotting that and sharing the fix, really nice catch! I've also never really been happy with use of This is great timing because the upstream project has not changed since the last stable release, so I will make this fix and push it as the new stable version. Any problems should then be traceable to the entrypoint script and not project code changes. I believe that the changes won't break anybody's install... (he said, ominously). According to my testing, and from WORKS
DOES NOT WORK
|
Running in kubernetes, it works fine except the EXTRA_LAUNCH_ARGS are not honored as env vars.
The following I would expect to enable the api and preload a model, neither are enabled though.
full kubernetes deployment:
The text was updated successfully, but these errors were encountered: