4

I run the following .desktop file in Gnome, to start my Remote Session:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=xfreerdp RDP
Comment=A sample application
Exec=/usr/bin/xfreerdp +clipboard +smart-sizing -decorations /u:myuser /d:DOMAIN /v:pc.domain.com /f /kbd:0x00000807 /fonts
Icon=/home/user/.local/share/applications/rdp.png
Terminal=true

This will open a Terminal window to type the password for the session. After i fill in the passwort, the session start. Now, if i close the terminal, the Remote Session also closes.

How do i prevent that?

What i tried so far is, instead to start xfreerdp directly, run a bash script, which usese '&' for spawnig, which not worked. Here is how this is look like:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=xfreerdp RDP
Comment=A sample application
Exec=/home/user/.local/share/applications/xfreerdp.sh
Icon=/home/user/.local/share/applications/rdp.png
Terminal=true

Here is the xfreerdp.sh script:

echo "password:"
read p
/usr/bin/xfreerdp +clipboard +smart-sizing -decorations /p:$p /u:user /d:DOMAIN /v:pc.domain.com /f /kbd:0x00000807 /fonts &
Improve this question
5
  • You could try your bash script again but add a disown after the command & line. Commented Aug 10, 2023 at 11:17
  • Is it possible your app tries to write something to stdout, and when the terminal is closed your app crashes since it has no terminal to write to? Try to redirect stdout to /dev/null to see if it helps. Also, leave the gnome desktop file for now, do all tests in a regular shell, gnome is just a distraction. Commented Aug 13, 2023 at 16:40
  • @aviro you are right: When i append "2>&1 /dev/null" to the script call, i can close the terminal window, and the xfreerdp still remains. I wasnt aware that this could be a problem. Thank you very much! Commented Aug 14, 2023 at 5:56
  • Just one question. You said you type the password in the terminal. If you redirect both stdout/stderr to /dev/null, doesn't it mean you don't see the password prompt? Commented Aug 14, 2023 at 7:16
  • Ive updated the Question. This is my setup Commented Aug 14, 2023 at 13:53

1 Answer 1

Reset to default
2

There are several different possible reason for that. One possible reason is that the STDOUT/STDERR get closed when you close the terminal, and then your program might die if it tries to output something. In order to solve it, just redirect your command to /dev/null:

/usr/bin/xfreerdp <ARGS> 1>/dev/null 2>&1 &

But that's not necessarily the preferred solution for your problem (even if it works, according to your response in the comments). Read further to find the best practice for those cases:

Another possible reason is that the terminal emulator you're using (xterm / konsole etc) might send a SIGHUP signal to its children when it terminates, and this signal might lead to their termination. In order to solve this problem, you can run your command with nohup:

run a command immune to hangups, with output to a non-tty

Notice that nohup also redirects the STDOUT/STDERR of the command you run to a file. From the man pages:

       If  the  standard output is a terminal, all output written by the named
       utility to its standard output shall be appended to the end of the file
       nohup.out  in  the current directory. If nohup.out cannot be created or
       opened for appending, the output shall be appended to the  end  of  the
       file nohup.out in the directory specified by the HOME environment vari-
       able.

So if you use this command, there's no need to perform the redirection.

nohup /usr/bin/xfreerdp <ARGS> &
Improve this answer
3
  • This solves my problem! Thank you very much aviro for this great explanation. The final statement in my script looks like this: nohup xfreerdp <ARGS> > /dev/null & One strange behaviour i noticed was, i need to add sleep 10 after the xfreerdp command, because the terminal just closes after i typed in my password? Commented Aug 14, 2023 at 18:57
  • @catMan Why is that a problem? Why do you need the terminal? It's not like it's an interactive shell, it's just a script. Also, how is it different than before? Also, why do you think it's strange? Your terminal emulator runs a script. The script runs your command in the background. Then, since the command is in the background, the script has nothing left to do so it terminates. Then his parent, the terminal emulator, has no more children so it also terminates, while your xfreerdp command keeps running at the background. That's exactly the expected result. Commented Aug 15, 2023 at 8:07
  • the strange thing is, xfreerdp are not executed if I dint put sleep at the end? It just closes the terminal without running xfreerdp. This is not what im expecting Commented Aug 15, 2023 at 9:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.