ydbinstall script checks for Supported or known Supportable platform and issues a warning otherwise #255
Comments
|
Can you run the following. This should turn on shell verbose mode and give us more information to debug. Thanks. $ set -x
$ . /usr/local/lib/yottadb/r122/ydb |
|
David,
You are getting this b/c you are running this script in a docker container.
Just run mumps -dir. that will work.
…On Wed, May 16, 2018 at 4:12 PM Narayanan Iyer ***@***.***> wrote:
Can you run the following. This should turn on shell verbose mode and give
us more information to debug. Thanks.
$ set -x
$ . /usr/local/lib/yottadb/r122/ydb
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#255 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABEtwnIeP-UaHRUS6x5dRq3qoFXuc8JNks5tzIgzgaJpZM4UB8Ho>
.
|
|
@shabiel : Do you know why one gets this error in a docker container. Thanks. |
|
I am NOT running this inside a docker container. As requested I ran:
DJW: if you have any more questions, I'll gladly try again. (or if you want me to put debugging statements in the shell scripts... etc. |
|
Sorry. accidentally closed and commented instead of just commented. |
|
Can you post the output of "env | grep gtm" and "env | grep ydb" commands before you run the ydb script. |
|
[whitten@here ~]Linux$ sudo su - ydb |
|
@whitten : I suspect you had a ~/.fis-gtm directory already existing and now you are using YottaDB which will create ~/.yottadb and verify that ~/.fis-gtm is soft-linked to ~/.yottadb and fail that check. Is it possible for you to move away ~/.fis-gtm to something else. I think that should get you going. |
nars1
changed the title
|
@whitten : Forgot to mention. We will fix the ydb script (in the next YottaDB release) to not error out if a ~/.fis-gtm directory exists. |
nars1
changed the title
|
The problem with the ~/.fis-gtm directory cannot be what is happening. I created a new user named "test" (with no .fis-gtm subdirectory) and it evidences the same behavior. |
|
In that case, can you run ydb with set -x enabled and send the output. Thanks. |
|
I am hoping the output will be different for the "test" user. |
|
[whitten@here ~]$ sudo adduser test
YDB>
./.mozilla: ./.mozilla/extensions: ./.mozilla/plugins: ./.yottadb: ./.yottadb/r: ./.yottadb/r1.22_x86_64: ./.yottadb/r1.22_x86_64/g: ./.yottadb/r1.22_x86_64/o: ./.yottadb/r1.22_x86_64/o/utf8: ./.yottadb/r1.22_x86_64/r: |
|
So why do you want me to just use "set -x" when I've already shown that the other options give you more information? |
|
@whitten from this output I see that there is only one obvious error: bash: /tmp/yottadb/r1.22_x86_64/test_20180518203518UTC_mupip_recover: Permission denied can you run this command: |
|
I wanted at least a set -x done. I did not see the other output when you mentioned "test" user has the same issue so I asked. Other options are fine too. The new output confirms this is a different issue happening much later than for the "ydb" user in your first report. I will look. |
|
$ ls -la /tmp/yottadb/r1.22_x86_64
|
|
I can't find the previous output (when I used more set options) because you edited what I sent you and deleted it. |
|
"test" user does not have write permissions to write to the directory that was originally created by the "ydb" user. Can you give write permissions on that directory for "test" user and rerun the ydb command. I expect it to go past this hurdle. |
|
I don't need the more output. Just a set -x is good enough. I edited it because there was more information than needed for me to analyze. |
|
Assuming the write permission trick works for "test" user, I will enhance the description to also address this multi-user issue in the ydb script. |
|
sudo chmod o=rwx /tmp/yottadb /tmp/yottadb: /tmp/yottadb/r1.22_x86_64:
YDB>halt |
|
I assume this means the "ydb" script now works as "test" userid. Can you confirm. |
|
I still see the error about "fg" so I don't know what that message means. [test@here ~]$ set +x YDB>h |
|
That is puzzling. With verbose mode turned on (set -x) we do not see any YDBGTMMISMATCH message for "test" user but with verbose mode turned off we see it. Can you run once more with set -x and send the output. Also an ls -la $HOME output. Thanks. |
|
I see the %YDBGTMMISMATCH message in this: (and the permission denied again on the
YDB>h
|
|
Can you send the output of realpath /home/$USER/.fis-gtm and realpath /home/$USER/.yottadb |
|
[whitten@here ~]$ sudo su - test |
|
That is the issue. ydb expects the "realpath" utility to exist. What distribution of Linux is this? Is it possible to create a softlink from /usr/local/bin/realpath to the absolute path of the readlink executable. That should get ydb going fine. |
|
I meant /usr/local/bin assuming that is already present in your PATH environment variable. If not, you need to add it. |
|
@whitten I'm curious as to what Linux distribution and version you are using that doesn't have realpath. Thanks. |
|
I've talked to @whitten and it is a centos 6.4 machine. |
|
Then I am not surprised that there are errors. On RHEL, which CentOS tracks, the minimum supported OS release level is 7.x. With the much older versions of libraries on 6.x, I am surprosed that YottaDB binaries built on 7.x even run on 6.x. |
|
Would it be worth putting a check in for /etc/centos-release or /etc/redhat-release to indicate an unsupported/advanced platform? |
|
And also for RHEL 4 & 5? The universe of potentially Supportable, but not Support platforms is large. Since we don't actually test on CentOS, Scientific Linux, or Oracle Linux, all of which supposedly track RHEL, should we flag those as well? For anything that is not Supported, it is hard to a priori figure out what is Supportable and what is Unsupported. I don't have any good answers, but the path we have taken so far is to clarify what is Supported and leave the rest to our users. |
|
Right. The thought here is to put an explicit check for supported platforms (as you say the list is significantly shorter) and issue a warning if it isn't one of those platforms. At least then the user will know they are in unsupported territory. Just a thought. |
|
YottaDB r1.22's ydb runs as expected when there is a .fis-gtm directory but no .yottadb directory, creating the expected symbolic link from .yottadb to .fis-gtm: I will edit the summary and draft release note reflect an enhancement to the ydbinstall script to check /etc/os-release, and issue a warning if the distribution is not recognized or is older than the Supported version. |
ksbhaskar
changed the title
|
I edited the summary and draft release note. |
|
I think a check to make sure the OS is acceptable would be a good thing. |
|
so, I'm not sure a softlink would do it, but an alias might (since you have to pass the -e argument to readlink) . I'll try defining the alias and seeing if I see the errors. |
|
FYI: YDB>h |
…nown/supported; New --force-install option overrides this behavior Currently, the supported platforms/os-versions are Linux x86_64 : Ubuntu 16.04 and higher, RHEL 7.x and higher ARMV7L/ARMV6L 32-bit : Raspbian 9 and higher, Debian 9 and higher
… --force-install by removing supportable usage
Final Release Note
Description
I installed yottdb 1.22 into a Linux account named "ydb",
and ran the command "gtm" below, and got errors.
I'm not quite sure what to tell you, and realize after I ran this, that perhaps I should have run some other command than "gtm" i.e. "ydb" but as you can see, it made the same errors.
I don't know what information you need to have for a bug-report like this,
[ydb@here ~]$ /usr/local/lib/yottadb/r122/gtm
YDB>w 1
1
YDB>h
[ydb@here ~]$ /usr/local/lib/yottadb/r122/gtm
/tmp/ydb_env_30864_ZFOxtN/out: line 1: fg: no job control
dirname: missing operand
Try `dirname --help' for more information.
/usr/local/lib/yottadb/r122/gtm: line 20: /ydb_20180516210018UTC_mupip_recover: Permission denied
YDB>h
dirname: missing operand
Try
dirname --help' for more information. /usr/local/lib/yottadb/r122/gtm: line 32: /ydb_20180516210018UTC-20180516210026UTC_mupip_rundown: Permission denied find: invalid argument-exec' to-mtime' [ydb@here ~]$ dirname dirname: missing operand Trydirname --help' for more information.[ydb@here ~]$ /usr/local/lib/yottadb/r122/ydb
/tmp/ydb_env_30901_4GyfVL/out: line 1: fg: no job control
dirname: missing operand
Try `dirname --help' for more information.
/usr/local/lib/yottadb/r122/ydb: line 20: /ydb_20180516210653UTC_mupip_recover: Permission denied
YDB>h
dirname: missing operand
Try
dirname --help' for more information. /usr/local/lib/yottadb/r122/ydb: line 32: /ydb_20180516210653UTC-20180516210736UTC_mupip_rundown: Permission denied find: invalid argument-exec' to `-mtime'Issues identified by the above report
If "realpath" executable does not exist, then "ydb" script errors out with a %YDBENV-F-YDBGTMMISMATCH error. It needs to check if "readlink" is available in case "realpath" is not. And if so use that instead. On all linux systems, one of the two will most likely exist.
If $HOME/.fis-gtm directory exists, the "ydb" script errors out with a %YDBENV-F-YDBGTMMISMATCH error. The issue is that the ydb script assumes $HOME/.fis-gtm is a softlink to $HOME/.yottadb which is not guaranteed. It needs to continue even if .fis-gtm is not a softlink to .yottadb.
The ydb script errors out with a "${USER}_20180518192042UTC_mupip_recover: Permission denied" in case it is run by multiple users on the same box and those users are not in the same group. This is because the first user would create /tmp/yottadb/r1.22_x86_64 directory usually with no write permissions for the world and that would cause errors for the second user invocation of ydb. The script should prevent such errors from happening by using different temporary directories for different users.
Draft Release Note
The ydbinstall script checks for existence and contents of
/etc/os-release, and issues a “Potentially Unsupported platform" message if the file does not exist or identifies a Linux distribution or release that is neither Supported nor known to be Supportable.For the record, below is the original draft release note:
The ydb script works fine even if $HOME/.fis-gtm exists. In prior versions of YottaDB, this script issued various errors in this cases none of which identified the source of the problem. A workaround in those versions was to rename/remove the $HOME/.fis-gtm directory before running the ydb script and/or give world write permissions to the directory /tmp/yottadb/r1.22_x86_64 and/or create a soft link from realpath to readlink in case realpath does not exist in the system.
The text was updated successfully, but these errors were encountered: