July 10, 2015 at 14:42 #7670
I’m testing out NoMachine Enterprise server version 4.6.4-14 on Ubuntu 14.04 using client version 4.6.4 on Windows. I’m interested in buying some licenses for this, but only if I can get version 4 working. We’ve been using version 3 for some time now but have been having issues getting version 4 working on Ubuntu 12.04 and 14.04 (the problem does seem to be on the nxserver side).
When the nxserver starts up, it tries to start the nxd daemon over and over, but it immediately dies every time with “signal 13”. I can’t seem to find any insight in the debug logs as to what signal 13 is indicating, but the command that nxProcessCreate is trying to run is:
nxProcessCreate: ‘/usr/NX/bin/nxd’ ‘/usr/NX/bin/nxd /usr/NX/bin/nxd’ ‘HOME=/var/NX/nx LD_LIBRARY_PATH=/usr/NX/lib NX_FEATURES=myhost11,VMwareInc.VMwareVirtualPlatform,Linux,Ubuntu 14.04.2 LTS,3.13.0,x86_64,2,3956285440,311 NX_SYSTEM=/usr/NX NX_VERSION=4.6.4′ ’16’ ’18’ ’19’ ‘101’
…and that fails for some unknown reason.
When attempting to create a new virtual desktop with the “SSH” connection method, the same “signal 13” exit code is thrown and the child node process dies, failing to create a new virtual desktop (the user sees “session negotiation failed”).
nxProcessCreate: ‘/usr/NX/bin/nxexec’ ‘/usr/NX/bin/nxexec /usr/NX/bin/nxexec –node –user test –priority –mode 0’ ‘NX_FEATURES=svlchi6dkevin1,VMwareInc.VMwareVirtualPlatform,Linux,Ubuntu 14.04.2 LTS,3.13.0,x86_64,2,3956285440,311 NX_USER_GROUPS=test. NX_VERSION=4.6.4 SSH_CLIENT=10.10.106.83 62140 22 SSH_CONNECTION=10.10.106.83 62140 10.2.2.60 22′ ’18’ ’18’ ’17’ ‘101’
I’ve attached the nxserver.log file, divided into two portions since it’s rather large. The first portion is nxserver startup where you can see the nxd exiting on signal 13 over and over until it gives up. The next log is an attempt by a remote user to create a new KDE virtual desktop, where you can see the nxexec command exit on signal 13 and fail.
Any ideas on what’s causing this? Is there anything more I can do to debug this? Turning up the LogLevel to 7 is about all I’m aware of. And again, I’m interested in buying the licensed version of Enterprise Server, but only if I can actually get it to work.
Thanks!July 10, 2015 at 14:43 #7677BritgirlParticipant
Hello, the logs weren’t attached. Can you send them to forums[at]nomachine[dot]com? Make sure you reference your topic title. Thanks.July 13, 2015 at 08:53 #7679July 13, 2015 at 09:08 #7689BritgirlParticipant
My error, it’s forum@…….Not forums@…July 13, 2015 at 11:14 #7694rezaParticipant
It’s not only nxd that fails with signal 13. Even system tools like ‘netstat’, ‘ps’, ‘ck-list-sessions’ are failing in the same way.
Do you have AppArmor or SELinux enabled?
Can you check system logs to see why execution of all these commands is blocked?July 17, 2015 at 09:00 #7737
Definitely no apparmor or selinux installed (only required, related packages for KDE and such):
root@myhost1:/usr/NX/var/log# dpkg -l |grep -iw apparmor
ii libapparmor-perl 2.8.95~2430-0ubuntu5.1 amd64 AppArmor library Perl bindings
ii libapparmor1:amd64 2.8.95~2430-0ubuntu5.1 amd64 changehat AppArmor library
ii python3-apparmor 2.8.95~2430-0ubuntu5.1 amd64 AppArmor Python3 utility library
ii python3-libapparmor 2.8.95~2430-0ubuntu5.1 amd64 AppArmor library Python3 bindings
root@myhost1:/usr/NX/var/log# dpkg -l |grep selin
ii libselinux1:amd64 2.2.2-1ubuntu0.1 amd64 SELinux runtime shared libraries
ii libselinux1-dev:amd64 2.2.2-1ubuntu0.1 amd64 SELinux development headers
System auth.log does not record any instance of denying execution of those commands, though yes, I can see that everything seems to fail in the same way. Is there any way for me to manually reproduce those commands in an interactive session? It seems difficult to do since the nx user’s shell is /etc/NX/nxserver:
Is nx trying to run these commands with sudo privileges? syslog is totally empty as well, so the nxserver.log and nxerror.log are all I have to go on at the moment. Any insight you can provide on how to manually test these commands that nx is trying to run would be helpful.
Thanks!July 17, 2015 at 10:45 #7742rezaParticipant
Are you using LDAP?
How your installation is differ from?
Commands are not executed with help of sudo.
You can try to test them manually with:
$ sudo su - nx -s /bin/bash $ /bin/ps awwxo ppid,pid,sid,comm,args $ /bin/netstat -ln --protocol=unixJuly 20, 2015 at 10:01 #7748
I am using LDAP, yes, but the nx user is not an LDAP account.
Relevant PAM section for LDAP:
auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
When I run commands manually as the nx user with “su – nx -s /bin/bash” they all seem to succeed. I even did them with “su – nx -s /bin/bash -c ‘command'” and they worked.July 20, 2015 at 10:04 #7753
So I have narrowed it down to LDAP being in nsswitch.conf. Once I remove the “ldap” entries, the /usr/NX/bin/nxd daemon starts up properly and virtual desktops are started successfully.
Is there something about having ldap in the nsswitch that is known to cause these failures with signal 13?
# Example configuration of GNU Name Service Switch functionality.
# If you have the
glibc-doc-reference' andinfo’ packages installed, try:
# `info libc “Name Service Switch”‘ for information about this file.
hosts: files dns
protocols: db files
services: db files
ethers: db files
rpc: db filesJuly 21, 2015 at 08:48 #7772graywolfParticipant
newmanium, this looks an issue in nss_ldap.
You can find a patched 264 version of nss_ldap for Ubuntu 14.04 x86_64 here.July 31, 2015 at 13:25 #7857
Just to follow up on that last post: through my own testing I can see that libnss-pam-ldapd is NOT affected by the same bug and works great. I’ll probably go the route of just switching everything over to libnss-pam-ldapd + nslcd.July 31, 2015 at 13:42 #7866BilbotineParticipant
we are glad it works now!July 31, 2015 at 14:00 #7827
Thanks! That does seem to solve the issue when I install that .deb. However, I’d probably prefer to build that .deb myself. Is there a specific bug in nss_ldap that you could point me to so I can build something that includes the fix?
Also, do you know if nss-pam-ldapd works any better with NoMachine Enterprise? I already was considering changing all of my hosts to that library for LDAP anyway.July 31, 2015 at 15:08 #7872BilbotineParticipant
A patch is available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+748341
As for nss-pam-ldapd, it works fine with NoMachine. It’s not affected by any bugs known to us which may break our application.
This topic was marked as solved, you can't post.