Mth

Forum Replies Created

Viewing 15 posts - 61 through 75 (of 124 total)
  • Author
    Posts
  • Mth
    Contributor

    Hello.

    First let me elaborate on the available options.

    When you have a headless Linux machine and NoMachine free version installed
    and want to have access to graphic environment there are two ways to do it:

    1. You can start it yourself by running the Xserver (like Xvfb) then starting
    the environment (like “/etc/gdm/Xsession gnome-session”) there. This method
    is explained in the article https://www.nomachine.com/AR10K00710.

    2. You can let the NoMachine start its own Xserver on demand or by default.
    If there is no Xserver running on the machine and the server.cfg key
    DefaultDesktopCommand is set properly, during the first connection
    you will be prompted to create and connect to new desktop.

    That said, there are a few things to consider.

    1. The physical desktop itself has to be installed. So like in the example
    you provided (etc/gdm/Xsession gnome-session) both the Xsession script
    and gnome-session have to be present.

    2. When dealing with physical sessions, after changes in system it is good
    practice to restart the nxserver afterwards. NoMachine regularly checks the availability of Xservers but when no Xserver is found after a certain time, it checks at longer intervals.

    # /etc/NX/nxserver --restart

    3. When starting Xserver by hand (like Xvfb in the topic you provided) you
    have to make sure to start it as standard user and avoid starting it as ‘root’.
    That is unless you specifically want to do it, starting graphical environment
    as root can be dangerous. Here it is important to use the same user as the one
    you want to use to connect via NoMachine. When the users are different, please
    make sure that when on “no available sessions” screen the view is set to “All desktops” instead of “My desktops”.

    And additional article that may help: https://www.nomachine.com/AR07Q01037

    If there is nothing that helps in your problem, we could deduce more from the
    NoMachine logs.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    After gathering logs, please send them to forum[at]nomachine[dot]com using the title
    of that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Can’t connect until local user logged in #24454
    Mth
    Contributor

    Hello.

    I am terribly sorry, don’t know where the error came from, but of course this
    is MacOS, so the path is not /usr/NX, but /etc/NX.

    So the commands should be:

    ‘# /etc/NX/bin/nxserver –userlist’

    ‘# /etc/NX/bin/nxserver –useredit –administrator yes’

    Sorry for causing confusion.

    /Mth

    in reply to: Can’t connect until local user logged in #24442
    Mth
    Contributor

    Hello.

    Thank you for reporting the issue.

    The first question is, when there was only one user in the system, was the operating system configured to log in this user automaticly,
    or did you had to log in manually?

    Second, do you have free version of NoMachine installed on the MacOS? If not, there could be two issues: one, when on “no sessions available”
    screen, so please make sure the view is set to “All desktops”. The second is what account you are using: please make sure the user you are connecting with is marked as an administrator for NoMachine:

    # /usr/NX/bin/nxserver --userlist

    If it is not, please set it by running:

    # /usr/NX/bin/nxserver --useredit --administrator yes

    And try to connect again.

    With the easy stuff ruled out, please gather logs for investigation.

    Gather information from the MacOS system log, preferably by running:

    # cat /var/log/system.log | grep -e nxserver -e nxnode -e nomachine >> system.debug

    Also please collect NoMachine logs.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Please include the system.debug file and send them to forum[at]nomachine[dot]com using the title of
    that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Error is 104: connection reset by peer #24194
    Mth
    Contributor

    Hello

    From the logs you supplied it seems that the nxnode process that is accessing the physical desktop is segfaulting during the attach
    procedure. This is causing the player to disconnect and trying to reconnect again, which with nxnode dead is causing a misleading
    error “104: Connection reset by peer.”.

    The nxnode process is dying with signal 11, so there should be a trace in the system logs or, if you have core dumps configured
    a core file for investigation.

    We are trying to reproduce this issue, but we would be grateful for a backtrace from this core file.

    Please refer to the article https://www.nomachine.com/AR09L00810 on how to proceed with core file.

    /Mth

    in reply to: nxserver.bin 100% usage when no sessions active #24166
    Mth
    Contributor

    Hello

    The nxserver does a bit of monitoring in the background, NoMachine processes graphic environment tracking, which is not
    always readily available in the system.

    The 100% cpu usage after connection is unacceptable and abnormal though (unless of course there is a lot of swapping going on).

    Could you please gather some logs for us to check this issue?

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Please enable them, restart the nxservice:

    ‘# /etc/NX/nxserver –restart’

    and then connect to the machine.

    Also please include the strace for this nxserver.bin process.

    ‘# strace -f -p <nxserver.bin PID> &> strace.log’

    You can find the nxserver.bin PID in the top view. Please let this command run for a full cycle of 100% usage and then terminate it with ctrl-c.

    After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Duplicate processes when NoMachine server is running #24019
    Mth
    Contributor

    Hello.

    This doubling of processes is most likely caused by the NoMachine starting the virtual desktop because it cannot detect the physical
    desktop and the server.cfg key CreateDisplay is set to 1.

    To avoid NoMachine creating it on each startup you can edit

    /usr/NX/etc/server.cfg

    config file and set this key to 0 or comment it.

    This key may be set to 1 because when you first connected, NoMachine had no physical session detected, asked to create “Display on demand” (which is simple virtual session). When you select yes, there is a checkbox to select, which will make NoMachine to start this session automatically on startup.

    Setting it to 0 will make it stop, but it does not solve the issue that you have running physical desktop and NoMachine did not detect it.

    If this key is set to 0 and after doing

    # /etc/NX/nxserver –restart

    you would not get NX> 161 Enabled service: nxnode. and you cannot access your desktop, we would require logs
    to investigate this further.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

    /Mth

    in reply to: Black screen connecting to physical display #23893
    Mth
    Contributor

    Hello

    The good news is we were able to identify the problem, and the fix
    is under way. The bad news is that we cannot provide a straightforward
    workaround.

    The problem is happening because of the strange dbus service behavior.
    By the default dbus-daemon –session should be ran by the systemd
    whenever the user is logged. Here it does not happen and instead it
    is invoked during the start of the graphic environment by the gdm-x-session
    process.

    So we have three important processes running as gdm-x-session children:
    Xorg, dbus-daemon –session and gnome-session-binary. Unfortunately
    the dbus-daemon started like this lacks some of expected environment
    variables, and the NoMachine fails the detection badly.

    Please check if there is anything wrong with the dbus service for the user e.g. by
    running

    ‘systemctl status dbus.service’

    or checking if the file /usr/lib/systemd/user/dbus.service is present and viable.

    If there is nothing wrong there, or it is not a result of an accident and this
    behavior is intended, we may be able to provide with patched packages.

    /Mth

    in reply to: 1 mac out of 3 does not allow connections #23891
    Mth
    Contributor

    Hello

    There are a few things to consider here.
    Is the spinning wheel happening on connection before NoMachine login
    screen, after logging in, or is the connection established and then you see the
    rotating icon?

    Is anything happening on the problematic machine itself?

    Usually, upon installation there should be a popup (if necessary) to handle access rights, maybe it was denied or revoked afterwards?

    If we can’t establish that it’s a configuration issue, we would require logs.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s thread as the mail’s subject.

    We would need logs from the problematic target machine and nxplayer logs from the connection attempt (client side)

    Also please check the system logs/journal for any errors/warnings or strange
    entries considering loading of NoMachine services (localnxserver, nxserver, nxd).

    /Mth

    in reply to: Black screen connecting to physical display #23830
    Mth
    Contributor

    Hello

    First, to answer the doubt about the Nvidia drivers, as long as there is
    no problem on your side (everything is fine on physical screen), there
    is no problem with them on our side. Right now as we see it from our logs
    the problem is in between the Xorg display server and the NoMachine
    ability to detect it.

    We are still not fully sure on what causes this problem and trying to
    find a solution that would fix this.

    Could you please provide us with one more set of logs? This time please set
    the server logs to verbose mode by editing the /usr/NX/etc/server.cfg file
    and setting:

    ‘SessionLogLevel 9’

    and then restarting the server.

    ‘/etc/NX/nxserver –restart’

    After the restart please gather the logs as usual.

    Please note that this would print much more details into the logs, so you would
    want to turn it off afterwards.

    Thank you for great cooperation and patience on this issue.

    /Mth

    Mth
    Contributor

    Hello.

    Glad to know you can now connect.

    Can you explain what you mean when you write “it doesn’t show the authentication screen”? Are you talking about the Login Window screen, or administrator authorization when trying to access the directory? What exactly are you doing?

    /Mth

    in reply to: Black screen connecting to physical display #23689
    Mth
    Contributor

    Hello.

    Even if it did not work, it gave some insight to the issue.

    It seems something is interfering with the session detection mechanism. Always the same X server process is detected, regardless of the display parameter. This is the reason the proper session never gets detected. Because this is a relatively new version of Gnome, even if there is user desktop running already, there will be X server for login window.

    Strange thing is, we haven’t been able to reproduce that issue, at least on standard configuration of Ubuntu 19.04. Please give us some information about your configuration.

    1. Is it freshly installed Ubuntu 19.04, or updated from older version?
    2. Do you have any changes in gnome configuration? It looks like there is no
    Wayland running, but maybe that is the issue here that it is not detected.
    3. Do You have any virtual X servers running? (like vnc or xvfb)
    4. If You can, please provide us with output of

    ‘# ps -efjH’

    command. As you wrote the desktop environment is Gnome, we are mostly interested in the process tree of “/usr/sbin/gdm3” process.

    And of course any information about any changes in configuration of X server or desktop environment that is present on the system will be most helpful.

    Also as the problem is related to the multiple X servers running, there could be a possible workaround, that is you can try to enable the automatic login for the user, and then restart the gdm service. This will cause the X server for login window to be skipped – at least at first, any logout/login afterwards would have it back.

    You can then simply kill the “Xorg” process owned by the gdm user (with kill -TERM <pid>), as there is no real need for that second inactive session to be running in background at all time. It is a very weak workaround, but may be of some help.

    /Mth

    in reply to: Black screen connecting to physical display #23646
    Mth
    Contributor

    Hello

    I am very sorry I got the configuration files mixed up.
    The proper configuration is:

    1. In /usr/NX/etc/node.cfg:

    PhysicalDisplays :0-:1200

    2. In /usr/NX/etc/server.cfg:

    DisplayBase 1201

    Also please note the lack of ‘:’ in DisplayBase. I’m really sorry about the confusion.

    /Mth

    in reply to: Black screen connecting to physical display #23635
    Mth
    Contributor

    Hello.

    After analyzing the logs it seems that we have a problem with detecting physical session
    on Ubuntu 19.04 that has eluded us until now. We will hopefully have it fixed soon.

    In the meantime please try a workaround:

    1. Please edit the server.cfg file located by default in ‘/usr/NX/etc/server.cfg’. Uncomment and edit
    the key PhysicalDisplays, so it looks like:

    PhysicalDisplays :0-:1200

    2. Please edit the node.cfg file located by default in ‘/usr/NX/etc/node.cfg’. Uncomment and edit
    the key DisplayBase, so it looks like:

    DisplayBase :1201

    3. Restart the nxserver service:

    # /etc/NX/nxserver --restart

    Please let us know if this worked for you.

    /Mth

    Mth
    Contributor

    Hello.

    While there is no indication in the logs why there was problem with the session at first,
    the white screen is most likely caused by the Login Window screen on Wayland:

    2019-08-30 14:43:41 832.519  1068 NXSERVER checkLocalSession: found X server process: [Xwayland        /usr/bin/Xwayland :1024 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6]

    Currently NoMachine does not work well with Wayland when using proprietary drivers,
    or in virtual machines.

    In the logs we noticed a standard Xorg server, which should work, but there is no connection attempt.

    Please check if disabling Wayland on login window help in this case. Standard
    procedure on Ubuntu is to edit /etc/gdm3/custom.conf file and uncomment or add line:

    [daemon]
    WaylandEnable=false

    Please let us know if there are any more problems.

    /Mth

    in reply to: 500 ERROR: Cannot connect to the requested session #22814
    Mth
    Contributor

    Hello.

    First thing, from the process list, the nxserver with parameters

    –virtualsession –sessionid 13E01F5A403A80C32DFF113CDD094013

    means that NoMachine could not find the physical session and is creating a virtual session for you to connect. So the question is, is the machine you are trying to connect to (RedHat) headless, or maybe the Xserver providing service is disabled?

    If you can confirm there is a physical session running on that machine, there is a first problem – NoMachine was not able to detect the physical session.

    Second problem is with that virtual session itself, as you mention the directory

    F-C-slc14unw-1001-9838E2BA07BFF1EE5FF509D4F84AC661

    is created, the information here is that the beginning letter F means this is failed session.

    The most probable scenario here is that this session failed during the connection attempt, which produced the bizarre error that session does not exist.

    The fact that the last process list does not have any nxserver –virtualsession
    process running could mean the sessions are being created and rapidly failing.

    Unfortunately to investigate this issue further, we would require logs.

    Article on how to collect logs:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    After gathering logs, please send them to forum[at]nomachine[dot]com using the title of that forum’s
    thread as the mail’s subject.

    Also please check the node.cfg configuration file, usually located on linux here:

    /usr/NX/etc/node.cfg

    and see if the config key DefaultDesktopCommand is set properly to the desktop environment
    installed on the machine.

    /Mth

Viewing 15 posts - 61 through 75 (of 124 total)