Datasocket Open Error 42 only on executable (Linux)

[dirtyb15]

Have a strange problem, running Labview 2016 for linux.  Have a VI that opens shared variables through datasockets.  Works fine when using as a vi, but when i try and build and run as executable (on the same computer), i get DataSocket Open error 42.  Any ideas?  (No firewalls or anything like that, run as normal user, super user, all permission etc..  

[SoarOnSon]

Could you post screenshots of your code and the error you are getting? Are you running any antivirus software on your computer? Another user in the linked post solved this issue by removing/disabling their antivirus software (https://forums.ni.com/t5/LabVIEW/Open-datasocket-connection-error-42/td-p/2872094/page/2).

Josh S.

Applications Engineer | National Instruments

[dirtyb15]

Sure, attached is a simple vi that works as a vi, but fails as an application.  I am not running any antivirus software on this Linux Machine, and the windows shared variable server machine is also not running any antivirus software.

[dirtyb15]

Ignore the last attachment, had the I.P. address wrong.  Here is the correct address.

[SoarOnSon]

It may be helpful to see if you can use your default firewalls with the settings in the following link for DataSockets: Configuring Software and Hardware Firewalls to Support National Instruments Products (http://www.ni.com/white-paper/12402/en/). Check outgoing requests from your Linux machine to see if the request is being sent before the error occurs. 

[mikhail.musienko · Accepted solution]

I have faced the same error.

None of the suggestions posted in this thread have helped, so after a lot of tinkering around here is a root cause and the solution -

When the compiled executable access datasocket function call, it will look for a library called liblksock_impl.so which apparently is required for psp access.

Here is an extract from strace output:

stat("/home/*snip*/builds/psp_test/psp_test/resource/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)

The app looks at ./resource/ folder relative to the executable, /usr/local/lib and /usr/local/lib64/ .

By default liblksock_impl gets installed to /usr/local/lib64/LabVIEW-2017-64/liblksock_impl.so (for 2017 x64 rte).

The easiest fix is to create a symlink to the library in one of the three locations the app looks at.

/usr/local/lib or /usr/local/lib64/ are easier because it will fix all your application on that machine, but it (potentially) may cause problems if you want to use different RTE versions simultaneously.

I ended up creating a "resource" folder in the same folder as my application and created symlink there.

cd /path/to/compiled/application
mkdir resource
cd resource/
ln -s /usr/local/lib64/LabVIEW-2017-64/liblksock_impl.so liblksock_impl.so

Replace "LabVIEW-2017-64" with RTE version you are targeting.

Works well with both lvrt and lvrtdark.

[mikhail.musienko]

I have faced the same error.

None of the suggestions posted in this thread have helped, so after a lot of tinkering around here is a root cause and the solution -

When the compiled executable access datasocket function call, it will look for a library called liblksock_impl.so which apparently is required for psp access.

Here is an extract from strace output:

stat("/home/*snip*/builds/psp_test/psp_test/resource/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib64/liblksock_impl.so", 0x7ffe5e4257c0) = -1 ENOENT (No such file or directory)

The app looks at ./resource/ folder relative to the executable, /usr/local/lib and /usr/local/lib64/ .

By default liblksock_impl gets installed to /usr/local/lib64/LabVIEW-2017-64/liblksock_impl.so (for 2017 x64 rte).

The easiest fix is to create a symlink to the library in one of the three locations the app looks at.

/usr/local/lib or /usr/local/lib64/ are easier because it will fix all your application on that machine, but it (potentially) may cause problems if you want to use different RTE versions simultaneously.

I ended up creating a "resource" folder in the same folder as my application and created symlink there.

cd /path/to/compiled/application
mkdir resource
cd resource/
ln -s /usr/local/lib64/LabVIEW-2017-64/liblksock_impl.so liblksock_impl.so

Replace "LabVIEW-2017-64" with RTE version you are targeting.

Works well with both lvrt and lvrtdark.