How does remote command get assembled?

Forums / NoMachine for Linux / How does remote command get assembled?

This topic contains 2 replies, has 2 voices, and was last updated by Avatar capn.freako 4 weeks ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #23301
    Avatar
    capn.freako
    Participant

    Can you tell me how this node command, for instance, gets assembled?:

    ‘/bin/bash -c exec -a – /bin/bash -c ‘/etc/X11/xinit/Xsession default”

    And do I have any control over this, via configuration files?

    I’m asking, because I believe the quoting is wrong and that that’s why I’m having trouble connecting.

    I see warnings like this:

    2019-08-15 23:54:16 841.423 10815 NXNODE   WARNING! Process ‘/bin/bash -c exec -a – /bin/bash -c ‘/etc/X11/xinit/Xsession default” with pid ‘10857/10857’ finished with exit code 1 after 0,828 seconds.

    in my nxserver.log file.

    And I notice:

    (base) [centos@ip-172-31-4-247 ~]$ /bin/bash -c exec -a – /bin/bash -c ‘echo Test’

    (base) [centos@ip-172-31-4-247 ~]$ /bin/bash -c “exec -a – /bin/bash -c ‘echo Test'”

    Test

    I think those missing double quotes are my problem and would like to test my theory.

    NoMachine free version 6.7.6-x86_64.

    MacBook Pro (10.14.6) client trying to connect to headless AWS EC2 CentOS 7 (7.3.1611) server (GNOME).

     

    #23342
    Avatar
    Gega
    Participant

    Hello capn.freako,

    The command is correctly constructed but it’s not displayed with it’s original form in the logs.

    The only part of this command you can and might want to modify could be ‘/etc/X11/xinit/Xsession default’, but it’s not necessary since the problem isn’t related to the command construction.

    Could you confirm if the Desktop environment is working properly?

    .xsession-errors file in user’s home directory or system logs (such as syslog) might show some more information about why the session application terminates.

    #23350
    Avatar
    capn.freako
    Participant

    Sorry, this was a red herring.

    I had installed the Anaconda3 Python distribution, which overrides the system installation of Qt in a way that breaks both KDE and GNOME.

    Removing (i.e. – uninstalling) Anaconda3 fixed my problem.I am now able to get either KDE, or GNOME, up and running.

     

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

You must be logged in to reply to this topic.