! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Wrong forking behaviour
Status:
RESOLVED: MOVED
Product:
Xfce4-terminal
Component:
General

Comments

Description R. Diez 2018-07-20 16:41:52 CEST
While developing this script:

https://github.com/rdiez/Tools/blob/master/RunInNewConsole/run-in-new-console.sh

I have realised that xfce4-terminal forks on start-up. This is a problem for my script.

KDE's konsole has an option to control this. From its man page:

  Use --nofork to run in the foreground (helpful with the -e option).

I am not the first to be caught by this forking behaviour:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434863

Adding option --disable-server stops the forking. However, this option is documented as "Do not register with the D-BUS session message bus", which is apparently unrelated to forking.
Comment 1 Igor editbugs 2018-07-20 16:56:23 CEST
> Adding option --disable-server stops the forking. However, this option is documented as "Do not register with the
> D-BUS session message bus", which is apparently unrelated to forking.
Well, that's because it _is_ unrelated to forking.
Xfce4-terminal, like many other apps, is using a single-process approach. This means that if you have xfce4-terminal running and you run another one with the `xfce4-terminal` command, that doesn't start another process but instead opens a new window within the same process which allows to interact between terminal windows, e.g., move tabs from one window to another.
Running `xfce4-terminal --disable-server` does start another process that cannot interact with other xfce4-terminal processes running.

> While developing this script:
I'm not sure what your script is supposed to achive.
Could you please give an example you're running with your script and xfce4-terminal, and what is the desired result and how it differs from the actual result you're seeing?
Comment 2 R. Diez 2018-07-20 17:16:31 CEST
Please check out the link I mentioned for a similar use case:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434863

There is no need to use my script. Basically, I want to open a terminal, run a command inside it, and continue when the command has finished or the user has closed the terminal. That means that my shell should block until xfce4-terminal exits. That is why KDE's Konsole's documentation says "helpful with the -e option".

However, running this:

xfce4-terminal --command="bash"

will not block your Bash.

If I use --disable-server , is that option there only to have a single process? Or am I disabling other D-Bus features along the way?

But I have tested now a little further, and now I understand what is going on. The first [xfce4-terminal --command="bash"] command does block Bash, but if you issue another one while the first one is still open, it does not block.

So xfce4-terminal is not actually forking, it is passing the command to an existing instance and exiting straight away, without waiting for the command to finish. Whether your Bash blocks then depends on whether you have another instance open. That is quite nasty for the purposes of the --command option.
Comment 3 Igor editbugs 2018-07-20 18:20:14 CEST
The "-e/--command" option just runs a command in the terminal. It does not dictate whether that will be a separate process, and it should not be doing that.

If I understand you correctly and what you want is to run a command in a separate xfce4-terminal window from an existing xfce4-terminal window, then the only way to accomplish that I'm aware of is using the "--disable-server" option. That won't allow you to interact between the terminal windows but I guess that should be fine if you're going to use the second window just for running the command and nothing else.

Will this work for you?
Comment 4 Igor editbugs 2018-07-20 18:21:14 CEST
The above should read

"run a command in a separate xfce4-terminal window from an existing xfce4-terminal window and block the existing window shell, then..."
Comment 5 Egmont Koblinger 2018-07-20 19:14:44 CEST
FYI: gnome-terminal 3.28 (IIRC) adds a "--wait" option, I think this is what OP is looking for.
Comment 6 Igor editbugs 2018-07-20 19:23:38 CEST
(In reply to Egmont Koblinger from comment #5)
> FYI: gnome-terminal 3.28 (IIRC) adds a "--wait" option, I think this is what
> OP is looking for.
xfce4-terminal has a similar option: -H/--hold

However, I understand that isn't what they're looking for. The OP wants the _original_ terminal from which the new one running a command is created to hold until the new one is closed. This is not possible (also with gnome-terminal) unless they're a starting a new process which can be achieved by running `xfce4-terminal --disable-server`.
Comment 7 Egmont Koblinger 2018-07-20 22:01:01 CEST
"gnome-terminal --wait" is quite different from "xfce4-terminal --hold".

In case of "gnome-terminal --wait", this very command, the "gnome-terminal --wait" command itself will wait until the terminal emulator tab it launched closes. The server may or may not live on, it's irrelevant, but whenever that particular terminal tab that was created due to the "gnome-terminal --wait" option closes, then exits this "gnome-terminal --wait" command.

If I understand correctly, this is exactly what R. Diez is looking for.
Comment 8 R. Diez 2018-07-21 22:44:40 CEST
1) Option --hold is not what I am looking for.

2) I cannot find any documentation regarding any --wait option for gnome-terminal.

3) KDE's Konsole has this option, which is exactly what I want:

"Use --nofork to run in the foreground (helpful with the -e option)."

Effectively, the Konsole process does not exit immediately, but it waits until the command has finished running.

4) Maybe --disable-server is sufficient. If so, it should be documented what other features this option affects. Alternatively, or may be in addition to that,  option -e should document that, without --disable-server, the xfce4-terminal process will return immediately, or will return after the command has finished, depending on the weather. 8-)

Remember that this has already surprised other people, see the bug Debian report I linked at the top.

5) I am actually not opening an xfce4-terminal from another xfce4-terminal. I normally use my script from Emacs in order to open GDB on a new console window, while OpenOCD is connected to an embedded target. When the user quits GDB, or closes the console it is in, the shell script closes OpenOCD automatically. But there are more usage scenarios you can think about.
Comment 9 Egmont Koblinger 2018-07-21 23:18:10 CEST
Re 2: It's new in gnome-terminal 3.28. There's not much doc (it appears in --help-all's output), just pass it to gnome-terminal and you'll see.
Comment 10 R. Diez 2018-07-23 08:46:08 CEST
I installed Ubuntu MATE 18.04 in a virtual machine, and then manually installed gnome-terminal. It's this version:

GNOME Terminal 3.28.2 using VTE 0.52.2 +GNUTLS -PCRE2

Option --wait seems to be doing what I want.

By the way, not only --wait is pretty much undocumented, it's a little buggy as well. If I run "gnome-terminal --wait -- bash", and then type "exit" to quit Bash, it does work. If I close the window, Bash goes away, but gnome-terminal hangs. I also tested with "gnome-terminal --wait -- sleep 3".

But hey, such GNOME bugs is the reason why I prefer Xfce or MATE anyway. 8-)
Comment 11 Egmont Koblinger 2018-07-23 15:12:27 CEST
> it's a little buggy as well.

Filed against gnome-terminal at https://gitlab.gnome.org/GNOME/gnome-terminal/issues/16, thanks!
Comment 12 Igor editbugs 2018-07-24 00:09:49 CEST
(In reply to Egmont Koblinger from comment #7)
> "gnome-terminal --wait" is quite different from "xfce4-terminal --hold".
> 
> In case of "gnome-terminal --wait", this very command, the "gnome-terminal
> --wait" command itself will wait until the terminal emulator tab it launched
> closes. The server may or may not live on, it's irrelevant, but whenever
> that particular terminal tab that was created due to the "gnome-terminal
> --wait" option closes, then exits this "gnome-terminal --wait" command.
> 
> If I understand correctly, this is exactly what R. Diez is looking for.
Yeah, I'm sorry, I misinterpreted the command behavior.
Comment 13 Igor editbugs 2018-07-24 00:15:22 CEST
(In reply to R. Diez from comment #8)
> 4) Maybe --disable-server is sufficient. If so, it should be documented what
> other features this option affects. Alternatively, or may be in addition to
> that,  option -e should document that, without --disable-server, the
> xfce4-terminal process will return immediately, or will return after the
> command has finished, depending on the weather. 8-)
> 
> Remember that this has already surprised other people, see the bug Debian
> report I linked at the top.
'--disable-server' effectively starts another terminal process, this option has no relation to other options and may be used together with any of them or on its own.
The Debian bug is like 10 years old, and you are the first person I see that's complaining about this behavior, so I guess the use case of running a terminal process that's blocking the shell is just very minor.

> 5) I am actually not opening an xfce4-terminal from another xfce4-terminal.
> I normally use my script from Emacs in order to open GDB on a new console
> window, while OpenOCD is connected to an embedded target. When the user
> quits GDB, or closes the console it is in, the shell script closes OpenOCD
> automatically. But there are more usage scenarios you can think about.
So can you just add '--disable-server' into your script and resolve the problem?
Comment 14 R. Diez 2018-07-24 08:07:54 CEST
I already added that switch to my script.

Part of my request was to document what --disable-server does, and how it affects the blocking behaviour of the -e option, see point 4) above. The man page would be the best place for that.
Comment 15 Git Bot editbugs 2020-05-24 23:43:56 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/27.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #14544

Reported by:
R. Diez
Reported on: 2018-07-20
Last modified on: 2020-05-24

People

CC List:
1 user

Version

Version:
unspecified

Attachments

Additional information