This seems to be what #369 mentions, and #508 hopes to fix, but I was wondering if there is currently a workaround for this problem.
Basically while command=/some/path/executable works, it can break programs that try to look for files in the directory they were called from (since supervisor is technically running the executable from the root directory without cd-ing). For example I am trying to run a dedicated game server (starbound), which breaks when called in this manner since it causes it to try to find its config files in the root directory instead of the directory it is located in.
I can use
directory=/some/path
command=executable
But when I do I get an error that the says can't find command "executable", which makes sense since (as the above linked issues discuss) supervisor is not including the directory in its path.
I've been able to get around this when I'm running bash scripts like this:
directory=/some/path
command=/bin/bash script.sh
Since /bin/bash is a program in the PATH, and script.sh is being passed in as an argument. But have not been able to figure out a workaround that would let me do the same for an executable.
I realize that in regular linux you run an executable with ./executable for just this reason, since that way it looks in the current directory. However using
directory=/some/path/
command=./executable
Also seems to just give me the error can't find command './executable'. error.
Long story short, is there a workaround that I can use to make the executable run when also using the directory config option to make supervisor cd into a directory first?
I'm not terribly experienced with linux, but it seems that, in the same way that /bin/bash can be used to run bash scripts, maybe you can use another program in the PATH to execute the executable? So something like:
directory=/some/path
command=/bin/RUNEXE executable
where /bin/RUNEXE is a program in the PATH that then runs the executable as an argument?
never-mind, I figured out the workaround here:
directory=/some/path
command=/some/path/executable
you use directory to have supervisor cd first, and then still use the full path in the command. this way supervisor can find the executable, and executable does not break since supervisor first cd'd into its directory.
Oddly enough, despite similar syntax being used for other configuration options, the following:
directory=/some/path
command=%(directory)/executable
is not a valid option, which would be nice to avoid having to type out the full directory path twice
I am going to close this as a duplicate of #369 or #508, both of which are related and still open.
Another workaround:
directory=/some/absolute/path
command=sh -c 'some/relative/path/to/executable'
@dvogel is there any workaround for c executable files.
In CLI, I am using ./path/to/executable [args]
Another workaround:
directory=/some/absolute/path command=sh -c 'some/relative/path/to/executable'
Thanks! it worked like a charm
Another workaround:
directory=/some/absolute/path command=sh -c 'some/relative/path/to/executable'
Thanks, but using sh -c will cause orphan process issue when restart it w/ supervisorctl since it only "kill" the outer sh process.
Most helpful comment
never-mind, I figured out the workaround here:
you use directory to have supervisor cd first, and then still use the full path in the command. this way supervisor can find the executable, and executable does not break since supervisor first cd'd into its directory.
Oddly enough, despite similar syntax being used for other configuration options, the following:
is not a valid option, which would be nice to avoid having to type out the full directory path twice