Can’t Create Any Virtual Desktops or start nxd

Forum / NoMachine Cloud Server Products / Can’t Create Any Virtual Desktops or start nxd

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #7670
    newmanium
    Participant

    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!

    #7677
    Britgirl
    Participant

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

    #7679
    newmanium
    Participant

    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).

    #7689
    Britgirl
    Participant

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

    #7694
    reza
    Participant

    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?

    #7737
    newmanium
    Participant

    @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!

    #7742
    reza
    Participant

    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
    
    
    #7748
    newmanium
    Participant

    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.

    #7753
    newmanium
    Participant

    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

    #7772
    graywolf
    Participant

    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.

    #7857
    newmanium
    Participant

    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.

    #7866
    Bilbotine
    Participant

    Hi newmanium,

    we are glad it works now!

    #7827
    newmanium
    Participant

    @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.

    #7872
    Bilbotine
    Participant

    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.

Viewing 14 posts - 1 through 14 (of 14 total)

This topic was marked as solved, you can't post.