Can’t Create Any Virtual Desktops or start nxd

[newmanium]

Hi,

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!

[Britgirl]

Hello, the logs weren’t attached. Can you send them to forums[at]nomachine[dot]com? Make sure you reference your topic title. Thanks.

[newmanium]

Done. I just sent them to that email address. Also trying to attach them to this post with a different file extension (.txt this time).

Attachments:

1. nxserver_startup.txt
2. nxserver_create_virtual_desktop.txt

[Britgirl]

My error, it’s forum@…….Not forums@…

[reza]

Hello,

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?

[newmanium]

@reza,

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:
nx:x:113:20113::/var/NX/nx:/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!

[reza]

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=unix

[newmanium]

I am using LDAP, yes, but the nx user is not an LDAP account.

Relevant PAM section for LDAP:

/etc/pam.d/common-auth:
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.

[newmanium]

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?

 

/etc/nsswitch.conf:
#
# 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.

passwd:         compat ldap [UNAVAIL=return]
group:          compat ldap [UNAVAIL=return]
shadow:         compat ldap [UNAVAIL=return]

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

[graywolf]

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.

[newmanium]

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.

[Bilbotine]

Hi newmanium,

we are glad it works now!

[newmanium]

@graywolf,

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.

[Bilbotine]

Hi newmanium,

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.

[Author]

Posts