Open whitten opened 6 years ago
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 notifications@github.com 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 https://github.com/YottaDB/YottaDB/issues/255#issuecomment-389650248, 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.
@nars1 @shabiel I just created a docker container for the current master (r1.23) which uses the ydb script and it didn't generate any errors.
I am NOT running this inside a docker container. I just downloaded the master zip file from github and compiled the code for yottadb.
As requested I ran: [ydb@here ~]Linux$ set -x ; . /usr/local/lib/yottadb/r122/ydb
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 [ydb@here ~]Linux$ env | grep gtm [ydb@here ~]Linux$ env | grep ydb USER=ydb MAIL=/var/spool/mail/ydb PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ydb/bin PWD=/home/ydb HOME=/home/ydb LOGNAME=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.
@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.
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 [whitten@here ~]$ sudo ls -la /home/test total 28 drwx------. 3 test test 4096 May 18 14:30 . drwxr-xr-x. 14 root root 4096 May 18 14:30 .. -rw-r--r--. 1 test test 18 Sep 25 2014 .bash_logout -rw-r--r--. 1 test test 176 Sep 25 2014 .bash_profile -rw-r--r--. 1 test test 124 Sep 25 2014 .bashrc -rw-r--r--. 1 test test 500 Nov 27 2014 .emacs drwxr-xr-x. 4 test test 4096 May 13 2014 .Mozilla [whitten@here ~]$ sudo su - test [test@here ~]$ ls -la total 28 drwx------. 3 test test 4096 May 18 14:30 . drwxr-xr-x. 14 root root 4096 May 18 14:30 .. -rw-r--r--. 1 test test 18 Sep 25 2014 .bash_logout -rw-r--r--. 1 test test 176 Sep 25 2014 .bash_profile -rw-r--r--. 1 test test 124 Sep 25 2014 .bashrc -rw-r--r--. 1 test test 500 Nov 27 2014 .emacs drwxr-xr-x. 4 test test 4096 May 13 2014 .mozilla [test@here ~]$ env | grep gtm [test@here ~]$ env | grep ydb [test@here ~]$ set -x ++ printf '\033]0;%s@%s:%s\033\' test here '~' [test@here ~]$ usr/local/lib/yottadb/r122/ydb $ . /usr/local/lib/yottadb/r122/ydb
YDB> +++ dirname /home/test/.yottadb/r1.22_x86_64/g/yottadb.gld ++ cd /home/test/.yottadb/r1.22_x86_64/g /usr/local/lib/yottadb/r122/mupip rundown -region '' +++ date -u +%Y%m%d%H%M%S +++ date -u +%Y%m%d%H%M%S -bash: /tmp/yottadb/r1.22_x86_64/test_20180518203518UTC-20180518203708UTC_mupip_rundown: Permission denied ++ find /tmp/yottadb/r1.22_x8664 -name 'test' -mtime +42 -exec rm -f '{}' ';' ++ printf '\033]0;%s@%s:%s\033\' test here '~' [test@here ~]$ env | grep ydb
./.mozilla: total 16 drwxr-xr-x. 4 test test 4096 May 13 2014 . drwx------. 4 test test 4096 May 18 14:35 .. drwxr-xr-x. 2 test test 4096 Aug 18 2010 extensions drwxr-xr-x. 2 test test 4096 Aug 18 2010 plugins
./.mozilla/extensions: total 8 drwxr-xr-x. 2 test test 4096 Aug 18 2010 . drwxr-xr-x. 4 test test 4096 May 13 2014 ..
./.mozilla/plugins: total 8 drwxr-xr-x. 2 test test 4096 Aug 18 2010 . drwxr-xr-x. 4 test test 4096 May 13 2014 ..
./.yottadb: total 16 drwxrwxr-x. 4 test test 4096 May 18 14:35 . drwx------. 4 test test 4096 May 18 14:35 .. drwxrwxr-x. 2 test test 4096 May 18 14:35 r drwxrwxr-x. 5 test test 4096 May 18 14:35 r1.22_x86_64 lrwxrwxrwx. 1 test test 12 May 18 14:35 V6.3-004_x86_64 -> r1.22_x86_64
./.yottadb/r: total 8 drwxrwxr-x. 2 test test 4096 May 18 14:35 . drwxrwxr-x. 4 test test 4096 May 18 14:35 ..
./.yottadb/r1.22_x86_64: total 20 drwxrwxr-x. 5 test test 4096 May 18 14:35 . drwxrwxr-x. 4 test test 4096 May 18 14:35 .. drwxrwxr-x. 2 test test 4096 May 18 14:35 g drwxrwxr-x. 3 test test 4096 May 18 14:35 o drwxrwxr-x. 2 test test 4096 May 18 14:35 r
./.yottadb/r1.22_x86_64/g: total 392 drwxrwxr-x. 2 test test 4096 May 18 14:35 . drwxrwxr-x. 5 test test 4096 May 18 14:35 .. -rw-rw-rw-. 1 test test 20787200 May 18 14:35 yottadb.dat -rw-rw-r--. 1 test test 2560 May 18 14:35 yottadb.gld -rw-rw-rw-. 1 test test 69632 May 18 14:35 yottadb.mjl
./.yottadb/r1.22_x86_64/o: total 12 drwxrwxr-x. 3 test test 4096 May 18 14:35 . drwxrwxr-x. 5 test test 4096 May 18 14:35 .. drwxrwxr-x. 2 test test 4096 May 18 14:35 utf8
./.yottadb/r1.22_x86_64/o/utf8: total 8 drwxrwxr-x. 2 test test 4096 May 18 14:35 . drwxrwxr-x. 3 test test 4096 May 18 14:35 ..
./.yottadb/r1.22_x86_64/r: total 8 drwxrwxr-x. 2 test test 4096 May 18 14:35 . drwxrwxr-x. 5 test test 4096 May 18 14:35 ..
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: ls -la /tmp/yottadb/r1.22_x86_64
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: total 4 drwxrwxrwx. 2 ydb ydb 4096 May 16 14:59 r1.22_x86_64
/tmp/yottadb/r1.22_x86_64: total 8 -rw-rw-rw-. 1 ydb ydb 0 May 16 14:59 ydb_20180516205916UTC-20180516205920UTC_mupip_rundown -rw-rw-rw-. 1 ydb ydb 244 May 16 14:59 ydb_20180516205916UTC_mupip_recover -rw-rw-rw-. 1 ydb ydb 330 May 16 14:59 ydb_20180516205916UTC_mupip_set [whitten@here ~]$ sudo userdel test -r -Z [whitten@here ~]$ sudo adduser test [whitten@here ~]$ sudo su - test [test@here ~]$ set -x ++ printf '\033]0;%s@%s:%s\033\' test here '~' [test@here ~]$ source /usr/local/lib/yottadb/r122/ydb
YDB>halt +++ dirname /home/test/.yottadb/r1.22_x86_64/g/yottadb.gld ++ cd /home/test/.yottadb/r1.22_x86_64/g /usr/local/lib/yottadb/r122/mupip rundown -region '' +++ date -u +%Y%m%d%H%M%S ++ find /tmp/yottadb/r1.22_x8664 -name 'test' -mtime +42 -exec rm -f '{}' ';' ++ printf '\033]0;%s@%s:%s\033\' test here '~'
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 [test@here ~]$ source /usr/local/lib/yottadb/r122/ydb -bash: fg: %YDBENV-F-YDBGTMMISMATCH: no such job
YDB>h [test@here ~]$
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 [whitten@here ~]$ sudo su - test [test@here ~]$ set -x ++ printf '\033]0;%s@%s:%s\033\' test 3530-cyc '~' [test@3530-cyc ~]$ source /usr/local/lib/yottadb/r122/ydb
YDB>h
+++ dirname
dirname: missing operand
Try dirname --help' for more information. ++ cd /usr/local/lib/yottadb/r122/mupip rundown -region '*' +++ date -u +%Y%m%d%H%M%S +++ date -u +%Y%m%d%H%M%S -bash: /test_20180518213508UTC-20180518213522UTC_mupip_rundown: Permission denied ++ find -name 'test_*' -mtime + -exec rm -f '{}' ';' find: invalid argument
-exec' to `-mtime'
++ printf '\033]0;%s@%s:%s\033\' test here '~'
[test@here ~]$ ls -la $HOME
Can you send the output of realpath /home/$USER/.fis-gtm and realpath /home/$USER/.yottadb
[whitten@here ~]$ sudo su - test [test@here ~]$ realpath /home/$USER/.fis-gtm -bash: realpath: command not found [test@here ~]$readlink -e /home/$USER/.fis-gtm /home/test/.yottadb [test@here ~]$readlink -e /home/$USER/.yottadb /home/test/.yottadb
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:
$ ls -ld .fis-gtm .yottadb
ls: cannot access '.yottadb': No such file or directory
drwxr-xr-x 9 bhaskar gtc 317 May 15 14:36 .fis-gtm
$ /usr/local/lib/yottadb/r122/ydb
YDB>zsy "ls -ld .fis-gtm .yottadb"
drwxr-xr-x 9 bhaskar gtc 317 May 15 14:36 .fis-gtm
lrwxrwxrwx 1 bhaskar gtc 8 May 21 11:31 .yottadb -> .fis-gtm
YDB>halt
$
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.
I edited the summary and draft release note.
I think a check to make sure the OS is acceptable would be a good thing. I certainly did not know my OS was so out of date, and that GT.M could possibly have troubles. I was just reporting what happened when I tried to run the script.
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: [test@here ~]$alias alias gtm='source /usr/local/lib/yottadb/r122/ydb' alias l.='ls -d .* --color=auto' alias ll='ls -l --color=auto' alias ls='ls --color=auto' alias vi='vim' alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde' alias ydb='source /usr/local/lib/yottadb/r122/ydb' [test@here ~]$ydb -bash: fg: %YDBENV-F-YDBGTMMISMATCH: no such job dirname: missing operand Try `dirname --help' for more information. -bash: /test_20180523142342UTC_mupip_recover: Permission denied
YDB>h
dirname: missing operand
Try dirname --help' for more information. -bash: /test_20180523142342UTC-20180523142347UTC_mupip_rundown: Permission denied find: invalid argument
-exec' to `-mtime'
[test@here ~]$ls /tmp/yottadb/
r1.22_x86_64
[test@here ~]$ls /tmp/yottadb/r1.22_x86_64/
[test@here ~]$ls -la /tmp/yottadb/r1.22_x86_64/
total 8
drwxrwxrwx. 2 ydb ydb 4096 May 19 16:00 .
drwxrwxrwx. 3 ydb ydb 4096 May 16 14:59 ..
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 Try
dirname --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
1) 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.
2) 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.
2) 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.