jayltee

[jayltee]

I have resorted to doing a reinstall of NX at firstboot via systemd.  Knowing if/how to resolve the last post would be useful but is less important for now.

I am on vacation now until January.  Thanks for the work you have all done on this issue.

Cheers.

[jayltee]

Thanks for the idea but it doesn’t quite work. After doing the steps above (modified to work in my environment) I end up being unable to connect to the physical desktop and get an error saying no sessions available and “The server was unable to make the local display available or access to the local display is disabled.”

The status of the server looks different and I cannot work out how to get it to the previous state.

Before the script:

ischia:/usr/NX/etc # systemctl status nxserver.service
nxserver.service – NoMachine Server daemon
Loaded: loaded (/lib/systemd/system/nxserver.service; enabled)
Active: active (running) since Tue 2016-12-06 15:27:59 GMT; 2s ago
Main PID: 17694 (nxserver.bin)
CGroup: /system.slice/nxserver.service
├─17694 /usr/NX/bin/nxserver.bin –daemon
└─17749 /usr/NX/bin/nxd -p 3389

Dec 06 15:27:59 ischia systemd[1]: Started NoMachine Server daemon.

ischia:~ # /etc/NX/nxserver –status
NX> 161 Enabled service: nxserver.
NX> 161 Enabled service: nxnode.
NX> 161 Enabled service: nxd.

After the script:

ischia:/usr/NX/var/log # systemctl status nxserver.service
nxserver.service – NoMachine Server daemon
Loaded: loaded (/lib/systemd/system/nxserver.service; enabled)
Active: active (running) since Tue 2016-12-06 15:48:11 GMT; 5min ago
Main PID: 22370 (nxserver.bin)
CGroup: /system.slice/nxserver.service
├─22370 /usr/NX/bin/nxserver.bin –daemon
├─22398 /usr/NX/bin/nxserver.bin –connectionmonitor –node localhost:4000
└─22399 /usr/NX/bin/nxd -p 3389

Dec 06 15:48:11 ischia systemd[1]: Started NoMachine Server daemon.

ischia:/usr/NX/var/log # /etc/NX/nxserver –status
NX> 161 Enabled service: nxserver.
NX> 162 Disabled service: nxnode.
NX> 161 Enabled service: nxd.

########

How can I stop the “/usr/NX/bin/nxserver.bin –connectionmonitor –node localhost:4000” from happening? Is this why the nxnode service is disabled? If not, what can I do to resolve that?

NB. file ownership and perms are correct after the script has run.

If I reinstall NoMachine I get back to where it works but that is what I am trying to avoid doing.

Thanks.

[jayltee]

Sorry to go over this again but I create a single system image that I then install on many machines.  It is not feasible to reinstall on each one.  This was not an issue with Opensuse 13.1 as I was doing the same process there with no problem.

Is there a specific file that identifies the server/client that I may be able to wipe clean manually?  Maybe removing a file which gets recreated at startup?

[jayltee]

Hello again – unfortunately I did not test it fully and when I do my normal image deployment as mentioned before (dump of system A, restore on system B via PXE) the screenlock behaves as before the fix 🙁

I need to be able to deploy in this manner and it always worked on Opensuse 13.1 so please can you point me at a file or something that can be sanitised so the NX client and server do not think they are the same machine?

I can confirm that if I uninstall/reinstall the test package on one host then the screenlocking behaves as we had hoped between the two machines so it does smell of what you eluded to before regarding both machines believing they are the same.

Thanks in advance.

[jayltee]

The test fix provided worked with Leap 42 and XFCE.  Great work.  Please advise on an approximate time frame for the official release.

Thanks.

[jayltee]

On one machine I have just done ‘rpm -e nomachine_5.1.54_1’  followed by ‘rpm -ivh  /tmp/nomachine_5.1.54_1_x86_64.rpm’ plus a reboot.  The screen blanking does not work still – just in case you wondered.

I’ll wait for the test fixed version and try again.

[jayltee]

Sorry I have been on vacation.

I can confirm that I am using the free x86_64 version.

Just to explain a little more about  what I said before – I have been using NX since v3 on OpenSuse and have always taken an image from one machine (using the dump command) and then via a PXE boot I use the “restore” command so we have all identical installations in use.  Once the screen blanking support was added in NX v4 I have not had an issue whilst doing the dump/restore using OpenSuse 13.1 and I have done so on many occasions.  It is only since using Suse Leap 42.1 that I have hit this issue so if it is down to using the same image can you point me at a specific file or something that may be the cause?  Is it possible to “clean” a file so that I can continue to deploy my images in this manner?  It is not feasible to hand tend the reinstallation on each machine I deploy.

I am happy to test a fix if you supply a download location.

Thanks.

[jayltee]

As you have reproduced it, may I have a test version to confirm the fix works?

[jayltee]

I can confirm I connected from machine A to machine B which are physically separate for the test logs you have. Can you not see that from the ipaddresses in the logs?  I just looked in the nxserver.log I provided and can see the server address (which ends in .158) and the client (which ends in .81).

I do use the same system image for both machines (ie. dump machine A and restore to machine B) but I have done this forever and it was not an issue with opensuse 13.1.

I am willing to test a fix package.  Either tell me where to pick it up from or send it via email to my registered address (which by the way is not getting any notifications for this thread so I am having to refresh the webpage each day).

Cheers.

[jayltee]

Logs have been emailed.

[jayltee]

I did not receive an email notification that you had accepted/updated this item so apologies for the delay.

After I had raised this post I did some more tests as I wondered if the XFCE window manager was part of the issue.  Here’s what I found:
NB. Server is always Leap42 and user is logged in. If session is password locked, when NX connected you need to put UNIX password in to access session.

Windows-> KDE window manager & user session is password locked -> Screen is blanked (Good!)
Windows-> KDE & user session is unlocked -> Screen is blanked (Good!)
Windows -> XFCE window manager & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Windows -> XFCE & user session is unlocked -> Screen is blanked (Good!)

Mac -> KDE (did not have a machine available to test at this time)
Mac -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Mac -> XFCE & user session is unlocked -> Screen is blanked (Good!)

Leap42 -> KDE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Leap42 -> KDE & user session is unlocked -> Screen is open to everyone (Bad!)
Leap42 -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Leap42 -> XFCE & user session is unlocked -> Screen is open to everyone (Bad!)

Opensuse 13.1 -> KDE & user session is password locked -> Screen is blanked (Good!)
Opensuse 13.1 -> KDE & user session is unlocked -> Screen is blanked (Good!)
Opensuse 13.1 -> XFCE & user session is password locked -> After using UNIX passwd, screen is open to everyone (Bad!)
Opensuse 13.1 -> XFCE & user session is unlocked -> Screen is blanked (Good!)

I will look to gather the logs as you ask shortly.

Thanks, JT

[Author]

Posts