"pihole -c" causes pihole-FTL.log - errors / FTL v5.3.4

Max-Mustermann · December 27, 2020, 8:06pm

Pihole-FTL.log filled up with:

[2020-12-27 12:13:01.778 656/T21796] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

entries.

Anyone able to help on this behaviour?
Seems was there even before 5.3.4 upgrade.

Thanks,
BR,
Mike

jpgpi250 · December 28, 2020, 8:08am

My log also contains errors I haven't seen before, although different than yours:

[2020-12-28 07:18:04.106 5236/T16341] WARN: Could not write() everything in ssend() [/root/project/src/api/socket.c:229]: Broken pipe
[2020-12-28 07:22:02.781 5236/T16723] WARN: Could not write() everything in ssend() [/root/project/src/api/socket.c:229]: Broken pipe

Max-Mustermann · December 28, 2020, 8:59am

maybe topic for the development guys?

Max-Mustermann · December 28, 2020, 12:48pm

FTL-Log will be filled with

[2020-12-28 13:46:41.395 19626/T23562] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.317 19626/T23656] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.337 19626/T23659] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.515 19626/T23690] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.537 19626/T23695] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.563 19626/T23700] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer
[2020-12-28 13:46:47.585 19626/T23703] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

whenever padd.sh started

Max-Mustermann · December 28, 2020, 12:48pm

Pi-hole® v5.2.2, Web v5.2.2, FTL v5.3.4, PADD v3.4,
Telnet-Version conflict/problem?
pkg -l | grep telnet
ii telnet 0.17-41.2 armhf basic telnet client

Opened issue on github / padd.sh:

github.com/pi-hole/PADD

pihole-ftl v.5.3.4 / PADD v3.4 - telnet_connection_handler_thread

opened 12:57PM - 28 Dec 20 UTC

closed 09:06PM - 30 Dec 20 UTC

un99known99

Bugfix in progress

*Before submitting a bug report, are you using a test version of Pi-hole? If so,… PADD doesn‘t support beta versions of Pi-hole!* **Describe the bug** pihole-ftl.log is filling up with massive amount of warnings (the more the longer padd.sh runs) **To Reproduce** Steps to reproduce the behavior: 1. start padd.sh (version 3.4) 2. tail -f on pihole-ftl.log **Expected behavior** No warnings in pihole-ftl.log when padd.sh is being executed **Screenshots** [2020-12-28 13:48:56.967 19626/T24654] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer [2020-12-28 13:48:56.987 19626/T24657] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

korhant · December 28, 2020, 5:29pm

I have the same setup and same problem. After killing padd.sh, the error stops in pihole-FTL.log. However when I run pihole -c instead of padd, same error appears again.

I think the problem is not related with PADD but with FTL v5.3.4 update running a Chronometer.

Max-Mustermann · December 29, 2020, 11:05am

It is being worked on:

github.com/pi-hole/PADD

pihole-ftl v.5.3.4 / PADD v3.4 - telnet_connection_handler_thread

opened 12:57PM - 28 Dec 20 UTC

closed 09:06PM - 30 Dec 20 UTC

un99known99

Bugfix in progress

*Before submitting a bug report, are you using a test version of Pi-hole? If so,… PADD doesn‘t support beta versions of Pi-hole!* **Describe the bug** pihole-ftl.log is filling up with massive amount of warnings (the more the longer padd.sh runs) **To Reproduce** Steps to reproduce the behavior: 1. start padd.sh (version 3.4) 2. tail -f on pihole-ftl.log **Expected behavior** No warnings in pihole-ftl.log when padd.sh is being executed **Screenshots** [2020-12-28 13:48:56.967 19626/T24654] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer [2020-12-28 13:48:56.987 19626/T24657] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

korhant · December 30, 2020, 9:38pm

PADD v3.5 is out, no more telnet_connection_error in pihole-FTL.log
Thank you.

Max-Mustermann · December 30, 2020, 9:47pm

already installed .. confirmed, developer did good work - many thanks!

jpgpi250 · December 31, 2020, 7:53am

I'm NOT using PADD and I keep getting the error in the log.

[2020-12-31 07:10:20.854 5236/T28841] WARN: Could not write() everything in ssend() [/root/project/src/api/socket.c:229]: Broken pipe
[2020-12-31 07:16:02.559 5236/T29721] WARN: Could not write() everything in ssend() [/root/project/src/api/socket.c:229]: Broken pipe

Max-Mustermann · December 31, 2020, 8:28am

padd.sh is working, pihole -c still errors

[2020-12-31 09:27:26.555 19626/T2718] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

Max-Mustermann · December 31, 2020, 8:34am

opened again bug report

github.com/pi-hole/pi-hole

pihole-ftl v.5.3.4 / "pihole -c" - telnet_connection_handler_thread / still not fixed

opened 08:31AM - 31 Dec 20 UTC

closed 12:11AM - 13 May 21 UTC

un99known99

Fixed in next release

Steps to reproduce the behavior: start pihole -c tail -f on pihole-f…tl.log Expected behavior No warnings in pihole-ftl.log when "pihole -c" is being executed Screenshots [2020-12-31 09:27:26.555 19626/T2718] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer [2020-12-31 09:27:26.609 19626/T2729] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer [2020-12-31 09:27:26.631 19626/T2733] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

Max-Mustermann · December 31, 2020, 11:07am

will be fixed in next release:

github.com/pi-hole/pi-hole

Fix connection mechanism between Chronometer and FTL

pi-hole:development ← pi-hole:fix/chronometer_connection_reset

opened 09:28AM - 29 Dec 20 UTC

DL6ER

+6 -4

**By submitting this pull request, I confirm the following:** - [X] I have r…ead and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template. - [X] I have made only one major change in my proposed changes. - [X] I have commented my proposed changes within the code. - [X] I have tested my proposed changes, and have included unit tests where possible. - [X] I am willing to help maintain this change if there are issues with it later. - [X] I give this submission freely and claim no ownership. - [X] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1) - [X] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)) --- **What does this PR aim to accomplish?:** Fix connection mechanism between Chronometer and FTL The existing interaction script between Chronometer (`pihole -c`) and FTL had a few drawbacks: 2. The connection was closed "suddenly" while FTL was waiting for the next query, resulting in a warning in FTL's log. 1. `read` is a `bash`-internal and does not populate. As a result, the existing check for `$?` didn't work and chronometer would have stalled forever if the connection was interrupted midway. **How does this PR accomplish the above?:** The two points are addressed with two changes: 1. Send `>whatevercommand > quit` to signal FTL that the pipe is to be closed when done sending the results of the query. This resolves the seen warnings properly. 2. Check for an empty returned value by `read` *and* a closed file descriptor `3`. This is the proper way to check for a terminated connection. Relying on the (non-existing) return value of `read` is removed as well as the check for a string `EOM` in the payload. **What documentation changes (if any) are needed to support this PR?:** None --- These fixes should be applied to PADD as well after they have been evaluated and approved.

Max-Mustermann · January 12, 2021, 6:44pm

despite update today
Core: v5.2.2.
Web: v5.2.2.
FTL: v5.3.4.

still not fixed - calling pihole -c

[2021-01-12 19:38:04.186 2402/T5429] WARN: Could not recv() in telnet_connection_handler_thread() (/root/project/src/api/socket.c:319): Connection reset by peer

pihole -up providing update to FTL, after sometime again pihole -up shown FTL update ?!? Kind of loop?!?

jfb · January 12, 2021, 7:08pm

This is not the next release. It's only in the development branch now.

Max-Mustermann · January 12, 2021, 7:09pm

then strange why pihole -up gave me update for ftl ....

jfb · January 12, 2021, 7:10pm

You were likely on an earlier master. You are now on the latest master, which does not have the indicated fix that is currently in the development branch.

Max-Mustermann · January 12, 2021, 7:13pm

hm, okie, makes sense as the version no of ftl hasnt changed yet.
But how did it happen to get me on an "early master"?

jfb · January 12, 2021, 7:14pm

FTL 5.3.4 was released on 12/24/2020. If you have not updated Pi-hole since then, you were still on the previous version of FTL.

The pihole -c fix was merged into development on 12/31/2020, and this will be rolled into the next update of the master branch.

Max-Mustermann · January 12, 2021, 7:19pm

pihole -v gave me
Pi-hole version is v5.2.2 (Latest: v5.2.2)
AdminLTE version is v5.2.2 (Latest: v5.2.2)
FTL version is v5.3.4 (Latest: v5.3.4)

which is fine as of now.
Just running again pihole -up, giving me: