Failed to send hostname reply: Invalid argument #11626
Comments
|
hmm, this is weird. This suggests that some client does a DNS query via resolved, and then when resolved tries to respond to that, the sending of the reply fails. If you turn on debug loggin in resolved, is there anything interesting in that? set SYSTEMD_LOG_LEVEL=debug in systemd-resolved.service via Environment= for that. |
poettering
added
the
needs-reporter-feedback ❓
This bit repeated in the journal, I can send the full (debug) log if needed. Thanks for looking at the issue. |
|
I have been seeing the same behavior on Arch linux for the last couple months.
|
|
I have the same issue on a laptop running systemd version 243.51. The network will not start at all. On another laptop with systemd version 242.135, the network is up and running as expected. EDIT: tried downgrading the systemd packages to 242.84 but this did not help to resolve the problem. Still no network - can't ping the gateway. |
|
I do have the same problem on archlinux-arm (aarch64) running systemd 243.78. I did have the same problem with 242.84 and the upgrade did not fix it. For me it has nothing to do with resuming from suspend. When I restart systemd-resolved it reproducibly stops working after a few minutes. The error I can see in the journal is just as @francoism90 described. |
|
Same, I have the same problem with systemd- resolved , anybody knows some solutions ? I have arch linux |
|
same, Archlinux. |
|
Same issue for me, 240-6ubuntu5.8 amd64. |
|
Same error flood here, even not when suspending/resuming. |
|
Can confirm this problem is still around on arch, systemd 245.6-7-arch. No suspend/resume involved - it just happens, usually after the network has been up for 3-4 hours, and running on debug logging for such periods of time would be rather problematic for me. |
|
same issue for me, ubuntu 20.04 |
|
Same issue, brand new install of Arch Linux. |
I managed to solve this after looking at the congested 2.4ghz band at my place and doing some adjustments to free up some channels to accomodate my wifi. It works fine now for now. If I encounter it again I will post. Suggest you guys to try the same. |
…he transaction We must have the error number around when completing the transaction. Let's hence make sure we always initialize it *first* (we accidentally did it once after). Fixes: systemd#11626
…he transaction We must have the error number around when completing the transaction. Let's hence make sure we always initialize it *first* (we accidentally did it once after). Fixes: systemd#11626 (cherry picked from commit fd8a301)
…he transaction We must have the error number around when completing the transaction. Let's hence make sure we always initialize it *first* (we accidentally did it once after). Fixes: systemd#11626 (cherry picked from commit fd8a301) (cherry picked from commit 38ae73f)
|
The error is still there for me on Ubuntu 20.04.2, using |
|
@zee-bit this is the upstream bug tracker. We close issues when they are fixed in our upstream tree, which this was with version 248. If you run something older, then please ping your distro about it and they might do something about it and backport the fix. But this is not the right place to request such a backport. |
|
If anyone runs into this issue on Ubuntu 20.04, you can go to https://bugs.launchpad.net/canonical-identity-provider/+bug/1946667 and add yourself as affected user. |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
The text was updated successfully, but these errors were encountered: