Forum Replies Created
-
Posts
-
Hi @Britgirl,
Thanks for the tip!
graphical.target and default.target aren’t fixing it as systemd discards them both as it detects a wrong cycle, but multi-user.target does the trick which makes sense, because it’s invoked prior to logging in. Then nx server starts correctly at gdm3 and you can connect and log-in remotely.
This should fix the problems for these users too – https://forum.nomachine.com/topic/no-available-desktop-on-this-server-with-dummy-displayport as logins
@Britgirl – I am reproducing this problem as well on 22.04.3 with Wayland. You can use the same log for referencing – https://forum.nomachine.com/topic/how-to-speed-up-nm-server-startup-at-boot#post-45867
I am on 22.04.3 and facing the same issue with Wayland after last weeks’ distro LTS updates. Tested v7 and v8.1 servers and it’s the same behaviour. You have to reboot the server on login in order for it to start. Otherwise it takes 10-15 minutes. Not sure if it will start at all if you can’t physically log in, or how long that would take, but I don’t have the time to test this during the week.
See nxserver debug level logs attached, there’s nothing useful elsewhere.
I am suffering from the same bug in Gnome Wayland sessions. The server doesn’t always start at boot.
Nov 06 18:44:09 systemd[1]: nxserver.service: Deactivated successfully.
Nov 06 18:44:09 systemd[1]: nxserver.service: Consumed 4.054s CPU time.
Hi @Britgirl, thank you for your prompt reply! That’s helpful and it works to an extent, but it still relies on an open socket in order to take over control. Adding sleep arguments in the script works, but if you stop moving the cursor, the socket gets occupied again by the bot/automation script, and you have to wait for the next sleep/opportunity to take over precedence. The “-eventdelay 0” argument works great for actual hardware input, where the same is not coming from a virtual uinput in udev and can coexist in Wayland. Anyway, I won’t nitpick as this is possibly something that <1% of everyone using your software, will ever notice. I’m very interested whether running the last v7 server will work, and if it will, for how long, with the newer clients (Android & dekstop)? Are there any incompatibilities that I must be aware of, or any crashes that this may cause, because stability is of course what’s most important for me. I’ve noticed the rare core dumps and frozen sessions with the old v7 server in Wayland, which may be attributed to the then working HA. Is this something you’ve worked on/fixed in the newer version?
Whom should I approach for a .DEB package of NoMachine 7.10.2.800 (or whichever is the latest v7 server version)? Will stopping automatic updates work, as I see they currently install automatically, as the option gets re-enabled after reboot even if you try to opt out (possibly due to a configuration/UI bug)?
Hi guys, I can confirm I’m experiencing the same behaviour as OP and @opticblu above on Ubuntu 22.04 jammy, kernel 5.15.0-50 with NoMachine server & clients 8.2.1 in Wayland.
the host is Intel Core i5-4460 & AMD CAICOS (DRM 2.50.0 / 5.15.0-50-generic, LLVM 13.0.1) and the clients are numerous.
I’ve tested this from (and to) Arch, from Windows 7/10 and Android devices, and it’s always SW encoding / HW decoding for the linux host machine, which results in poor performance and increased CPU usage. It was working splendidly for years with your version 7 on Ubuntu 20.04, 21.04, 21.10 and 22.04 as well, until the update to v8.
There are two other issues I’m aware of, that came with your v8 release. https://forums.nomachine.com/topic/white-screen-after-first-connect-since-v8 which I noticed from the get-go and can also confirm, but that’s really low impact.
However, what is highly impacting my work, is that you’ve changed the way you pick mouse position in Wayland, directly from udev which conflicts with other virtual input devices, blocking access to the remote desktop’s input, when the same is running an automation task. To test this, run a simple mouse click event while loop on the host, with ydotool, and attempt to get mouse movements/control on the NoMachine client side. Your Linux devs will know what I’m talking about.
I am seconding @opticblu’s request above. Can we have the old server version 7 (latest release before 8)?? Because quite frankly, I don’t have the time to engage into log submission, bug tracking, etc. for the software encoding issue (which I suspect is global for anyone using the host in Linux, or Wayland at least), since you’re not going to change your core logic and the way you utilise mouse/kbd input, which is the real problem for me. I currently have to run crons and kill-switches on session start, just to regain control of the host machine’s input.
Your Android app is unparalleled when it comes to ease of access and keyboard functionality, and with Wayland support, you’ve been paramount to a whole section of the Linux comunity. We’re not going anywhere, we just want to use the old v7 server.