[Solved] in havoc terminal emulator: yes causes broken pipes

[GNUser]

Hi jazzbiker. yes-related "Broken pipe" messages still appear if I add this to /usr/bin/tce-load:

Code: [Select]

trap '' SIGPIPEI have submitted a bug report to the havoc developer.

[GNUser]

Hi Juanito. havoc developer says the pipe of interest is created by the shell, not the terminal emulator (see here). Moving blame from terminal emulator to shell helps explain why havoc and weston-terminal are both affected.

I use havoc + busybox ash 99.9% of the time. I tried havoc + bash as a test and problem did not go away.

Since all terminal emulators and shells seem to be affected, I think the problem may have something to do with how weston or labwc is being started. Can you suggest a way to start the graphical session different from this (which is what weston.tcz.info suggests):

Code: [Select]

sudo -- seatd -g staff -n /run/seatd.sock & XDG_RUNTIME_DIR=/run/user/$(id -u) weston
?

[jazzbiker]

Hi!

I've made some experiments trying to reproduce the observed by GNUser behaviour of yes. As it was described in the link by patrikg it looks rather counterintuitive.
I'm testing in TC14 x86 under Xorg.

Code: [Select]

tc@box:~$ yes | lua -e 'print(io.read())'
y
tc@box:~$ yes no | lua -e 'print(io.read())'
no
tc@box:~$ trap '' SIGPIPE # ignore signal
tc@box:~$ yes | lua -e 'print(io.read())'
y
yes: Broken pipe
tc@box:~$ yes no | lua -e 'print(io.read())'
no
here the pipeline hangs, interrupted by Ctrl-C

Code: [Select]

^Ctc@box:~$  trap - SIGPIPE # restore default handler
tc@box:~$ yes | lua -e 'print(io.read())'
y
tc@box:~$ yes no | lua -e 'print(io.read())'
no
tc@box:~$

So looks like havoc envokes the shell with SIGPIPE ignored. The cure may be restoring the default handler.

@GNUser, You may try adding

Code: [Select]

trap - SIGPIPEto tce-load or to yes wrapper.

Looks like it is havoc's fail cause it leaves the shell without the SIGPIPE handler. I can't guess why the same behaviour is exhibited by another wayland terminal emulator, looks like coincidence.

You can notice the changes in the yes behaviour when it is supplied with the output string.

[jazzbiker]

You can notice the changes in the yes behaviour when it is supplied with the output string.

In fact the difference in the yes behaviour is between single-char and multi-char output:

Code: [Select]

tc@box:~$ trap '' SIGPIPE
tc@box:~$ yes | lua -e 'print(io.read())'
y
yes: Broken pipe
tc@box:~$ yes n | lua -e 'print(io.read())'
n
yes: Broken pipe
tc@box:~$ yes no | lua -e 'print(io.read())'
no
^Ctc@box:~$ # hung up and interrupted by Ctrl-C


[Rich]

Hi jazzbiker
Nice find. Works under TC10 x86 too:

Code: [Select]

tc@E310:~$ busybox yes | head -n 3
y
y
y
tc@E310:~$ trap '' SIGPIPE
tc@E310:~$ busybox yes | head -n 3
y
y
y
yes: Broken pipe
tc@E310:~$ trap - SIGPIPE
tc@E310:~$ busybox yes | head -n 3
y
y
y
tc@E310:~$

... Looks like it is havoc's fail cause it leaves the shell without the SIGPIPE handler. I can't guess why the same behaviour is exhibited by another wayland terminal emulator, looks like coincidence. ...

Maybe they share a common code base. That can happen when
someone forks a program to implement changes they want.

Or maybe it's being caused by something else they share in
common, Wayland itself.

[GNUser]

Hi jazzbiker and Rich. Thank you. It's good to have more than one workaround.

But I confess I'm no closer to understanding the root problem.

Looks like it is havoc's fail cause it leaves the shell without the SIGPIPE handler.

I'm not sure it is havoc's fault. The developer tried hard but was unable to reproduce the issue. See here:
https://github.com/ii8/havoc/issues/50#issuecomment-1783859048

[Rich]

Hi GNUser
Quote from https://github.com/ii8/havoc/issues/50#issuecomment-1783907710

In havoc, ls | sort and all other pipelines work fine. Strangely, the problem seems limited to pipelines containing yes command. ...

Nothing strange about it:

Code: [Select]

yes "password" | bcrypt somefileyes  starts writing  "password"s  to the pipe (FIFO).
bcrypt  reads the first  "password"  and then the second one to confirm.
bcrypt  encrypts the file and then exits.
When  bcrypt  exits, the pipe gets destroyed.
When  yes  attempts the next write, it encounters a write error and terminates.

The way to stop  yes  is to terminate it with Ctrl-C, kill, break the pipe, etc.
The broken pipe is the normal way to terminate  yes , not an error in this case.

[GNUser]

Hi Rich. I can follow all of that and it makes perfect sense. What I'm trying to understand is why these "broken pipe" messages only appear in terminal emulators on TCL in wayland session. Here is the situation:

console on TCL: no error
terminal emulator on TCL in X session: no error
terminal emulator on other distro in wayland session (per havoc's developer): no error
terminal emulator on TCL in wayland session: error

[GNUser]

When  bcrypt  exits, the pipe gets destroyed.
When  yes  attempts the next write, it encounters a write error and terminates.

That's not what I'm seeing.  yes  is not exiting and enters an infinite loop after bcrypt gets the two lines it needs, driving CPU usage up and turning on my laptop's fans. Pressing Control+c does not stop the infinite loop. Only way to stop the infinite loop is to close the terminal emulator window:

Code: [Select]

$ echo "this is a test" >test.txt
$ yes "password" | bcrypt test.txt
Encryption key:
Again:
^C^C^C^C^C^C^C^C^C^C^C^C^C^C[laptop fans start running here, I close terminal emulator window, cpu usage goes down, fans stop]

[Rich]

Hi GNUser
Forgot about the infinite loop case. No idea about that.

[Rich]

Hi GNUser
I see you added an example to your post.

This is interesting:

Code: [Select]

tc@E310:~$ trap '' SIGPIPE  # Disable handler
tc@E310:~$ echo "this is a test" >test.txt
tc@E310:~$ busybox yes "password" | bcrypt test.txt
Encryption key:
Again:
^Ctc@E310:~$ # busybox yes enters infinite loop, Ctrl-C breaks us out.
tc@E310:~$
tc@E310:~$ echo "this is a test" >test.txt
tc@E310:~$ yes "password" | bcrypt test.txt
Encryption key:
Again:
yes: standard output: Broken pipe
tc@E310:~$ # GNU yes works.
tc@E310:~$
tc@E310:~$ trap - SIGPIPE  # Enable handler
tc@E310:~$ echo "this is a test" >test.txt
tc@E310:~$ busybox yes "password" | bcrypt test.txt
Encryption key:
Again:
tc@E310:~$ # busybox yes works.
tc@E310:~$
tc@E310:~$ echo "this is a test" >test.txt
tc@E310:~$ yes "password" | bcrypt test.txt
Encryption key:
Again:
tc@E310:~$ # GNU yes still works.
This seems to suggest there may be a bug in  busybox yes  when
there is no signal handler for  SIGPIPE.

If you use  GNU yes , does the problem go away?

[GNUser]

Hi Rich.

If you use  GNU yes , does the problem go away?

No.

I think I figured it out. Juanito sees this error in weston-terminal because that terminal ignores SIGPIPE (see here). In my case, I am seeing the error in havoc terminal because the terminal emulator inherits its environment from my compositor, labwc (version 0.6.5), which has been rigged to ignore SIGPIPE since version 0.6.3 (see here).

If  yes  is running in an environment where SIGPIPE has been disabled, it will either error out with "Broken pipe" or will enter an infinite loop, depending on the situation. Either way, it will not behave as expected.

[Rich]

Hi GNUser
So just to be clear, installing  coreutils  and executing the
following still results in an endless loop:

Code: [Select]

$ echo "this is a test" >test.txt
$ /usr/local/bin/yes "password" | bcrypt test.txt

[GNUser]

No. In that scenario an error is displayed but no endless loop. It seems only busybox  yes  enters the endless loop when used with  bcrypt  .

Code: [Select]

bruno@x230:~$ tce-load -wil coreutils
coreutils.tcz.dep OK
Downloading: coreutils.tcz
Connecting to gnuser.ddns.net (24.0.182.246:80)
saving to 'coreutils.tcz'
coreutils.tcz        100% |********************************| 2304k  0:00:00 ETA
'coreutils.tcz' saved
coreutils.tcz: OK
yes: Broken pipe
bruno@x230:~$ echo "this is a test" >test.txt
bruno@x230:~$ /usr/local/bin/yes "password" | bcrypt test.txt
Encryption key:
Again:
/usr/local/bin/yes: standard output: Broken pipe
bruno@x230:~$

[Rich]

Hi GNUser
And that's the point I was trying to make. GNU yes  prints
the error message after  bcrypt  completed successfully.
That's why I suggested it may be a  busybox  issue.