Rocket U2 | UniVerse & UniData

ROCKETEER Jonathan Smith posted 05-30-2022 04:30

Beth,

Normally running the relink.udlibs to point to the correct location where libunidata.so exists. The normal error I've seen when this is wrong is as below.

Dependent module libunidata.so could not be loaded.
Could not load module libunidata.so.
System error: No such file or directory

Your message references a permission denied message, so as a first step check the permissions on the libunidata.so, I would expect them to be

a) be owned by root
b) belong to the group system
c) have world permissions i.e rwxrwxrwx 

Go to your ublibs82 directory and do a 'ls -al' on the directory and check the permissions match those above for libunidata.so, if the permissions don't match change them to the above and try again. Please let us know the results.


Thanks,
Jonathan

Beth Chesnutt posted 05-31-2022 07:46

Jonathan,
Here is the output:
server> cd /usr/ud82/lib/uddlls
server> ls -al
total 48
drwxrwx--- 2 root system 4096 Apr 8 09:45 .
drwxr-xr-x 3 root system 4096 Apr 8 09:44 ..
lrwxrwxrwx 1 root system 25 Apr 8 09:45 libcrypto.a -> /usr/ud
82/bin/libcrypto.a
-r-xr-xr-x 1 root system 14992 Apr 8 09:44 libodbc.so
lrwxrwxrwx 1 root system 22 Apr 8 09:45 libssl.a -> /usr/ud82/
bin/libssl.a
lrwxrwxrwx 1 root system 27 Apr 8 09:45 libu2callc.so -> /usr/
ud82/bin/libu2callc.so
lrwxrwxrwx 1 root system 34 Apr 8 09:45 libu2callc_nfasvr.so -
> /usr/ud82/bin/libu2callc_nfasvr.so
lrwxrwxrwx 1 root system 27 Apr 8 09:45 libunidata.so -> /usr/
ud82/bin/libunidata.so
lrwxrwxrwx 1 root system 31 Apr 8 09:45 libunidata_rfs.so -> /
usr/ud82/bin/libunidata_rfs.so
lrwxrwxrwx 1 root system 31 Apr 8 09:45 libunidata_uci.so -> /
usr/ud82/bin/libunidata_uci.so
lrwxrwxrwx 1 root system 25 Apr 8 09:45 libvvrun.so -> /usr/ud
82/bin/libvvrun.so
server>

I did find a logical link in /datatel/coll18/coll18  which is the udt account and at / on this box for .uddlls.  Could the entry at /datatel/coll18/coll18 be the reason for the error? Can I just use cd /datatel/coll18/coll18 and rm .uddlls to remove the logical link without deleting the directory and files it points to?
Thanks,
Beth

ROCKETEER Jonathan Smith posted 05-31-2022 10:14

Beth,

You mention that /datatel/col18/col18 is the udt account, I'm not sure what you mean by this, do you mean this is the location of the account you trying to enter by using udt or is where UniData is installed, it would be strange if it was.

There are two types of link a symbolic link which is denoted with a small l 'l' is the ls -al listing,
If you rm a symbolic link it does not delete the file, if you delete a hard link it does not differentiate between the link and the file and both will be deleted.

If you perform a ls -al of the /datatel/col18/col18 directory what does it show for the output for the .uddlls entry, also what is the output from the ls -al on the entry in the root directory.

Thanks,
Jonathan

Beth Chesnutt posted 05-31-2022 12:33

Jonathan,
Yes, it is the account I am trying to enter when using udt.  I discovered by changing the permissions to 775 for /datatel/coll18/coll18, I was able to again login.  I still would like to delete the logical link since it should not be there.

Here is the display at the account level
chesnutt:/datatel/coll18/coll18>ls -al
total 656280
drwxrwxr-x 17 datatel users 8192 May 27 16:05 .
drwxrwxr-x 14 datatel users 4096 Feb 25 15:37 ..
lrwxrwxrwx 1 root system 20 Apr 8 10:42 .udlibs -> /usr/ud82/l
ib/uddlls

From root:
chesnutt:/datatel/coll18/coll18>cd /
chesnutt:/>ls -al
total 1320
lrwxrwxrwx 1 root system 20 Apr 8 10:52 .udlibs -> /usr/ud82/l
ib/uddlls
lrwxrwxrwx 1 root system 20 Jul 14 2019 .udlibs71 -> /usr/ud71
/lib/uddlls
lrwxrwxrwx 1 root system 20 Jul 14 2019 .udlibs72 -> /usr/ud72
/lib/uddlls
lrwxrwxrwx 1 root system 20 Jul 14 2019 .udlibs81 -> /usr/ud81
/lib/uddlls
lrwxrwxrwx 1 root system 20 Apr 8 09:45 .udlibs82 -> /usr/ud82
/lib/uddlls

Thanks,
Beth

ROCKETEER Jonathan Smith posted 06-01-2022 04:51

Beth,

It appears that someone has put those links in deliberately. Although you're safe to remove the link as it appears to be a symbolic link so it will not delete the linked file as well, I would ask around your organisation further before doing so, as it looks like it's been done for every UniData release ever put on the machine, so you may end up breaking something others are using if you remove the link. Check around first and if no one has any idea how they got there and you still want to remove the link, then please do so, you can always put them back if something else breaks.

Thanks,
Jonathan

Beth Chesnutt posted 06-01-2022 08:24

Thanks Jonathan for all your help.  I confirmed this was unintentional link and successfully removed it.  The folder it was pointing to is still intact as expected.