Resolved: can't fetch mail
- From: Jack <ostroffjh users sourceforge net>
- To: balsa-list gnome org
- Subject: Resolved: can't fetch mail
- Date: Mon, 08 Aug 2022 16:47:50 -0400
I don't see that I ever posted a follow-up, so better late than never.
I boot my PC to command line, and eventually start X (KDE.) The
network doesn't actually get set up until the KDE session takes care of
it. However, lately, it seems it has been connecting to enp0s2 (which
IS the persistent name of my ethernet card) but in that state, the
network isn't actually connected to anything. I have to explicit tell
the widget (network manager, I think) to connect to "Wired connection
1" instead. That fully brings up the network. Before I do that,
attempting to fetch mail fails, as Balsa doesn't think the network is
actually up. After that, fetching mail works fine. So - it's not a
Balsa problem at all. What is odd is that once I connect to Wired
connection 1, the other enp0s2 disappears from the list of available
networks. Something funny within the network manager, I suppose.
On 2022.06.07 15:33, Jack via balsa-list wrote:
Well, temporarily resolved, though not actually solved. First, it
took me two tries to realize that the g_network functions are in
glib, not gtk, but I got it recompiled with debug info. Tracing
through from balsa_window_init, I got totally lost in all the g_
functions, but at one point noticed (displaying local variables in
the debugger) that there had been a g_network_changed signal, and
the network now showed as available, and I successfully downloaded my
approx 120 queued messages. Unless something in compiling with -ggdb
also changed something else, and I can figure what it was, I might
have to chalk this up to "phase of the moon and blue magic dust."
On 2022.06.07 14:06, Jack Ostroff via balsa-list wrote:
Good timing - I'm finally digging into this right now. My smtp test
send was through gmail, so not local. I'm now compiling gtk with
debug symbols to see if I can find why it might think the network is
missing, or at least trace into those g_network calls. The "route"
command DOES show a "default" route to my router, to which I have a
wired connection. I also do NOT see any network-changed messages.
"grep -i network" on the output gives me:
(process:8898): GLib-GIO-DEBUG: 17:43:34.475: Failed to initialize
portal (GNetworkMonitorPortal) for gio-network-monitor: Not using
portals
(process:8898): GLib-GIO-DEBUG: 17:43:34.478:
_g_io_module_get_default: Found default implementation
networkmanager (GNetworkMonitorNM) for ?gio-network-monitor?
(balsa:8879): GLib-GIO-DEBUG: 17:43:34.700: Failed to initialize
portal (GNetworkMonitorPortal) for gio-network-monitor: Not using
portals
(balsa:8879): GLib-GIO-DEBUG: 17:43:34.702:
_g_io_module_get_default: Found default implementation
networkmanager (GNetworkMonitorNM) for ‘gio-network-monitor’
** (balsa:8879): DEBUG: 17:43:34.702: Networkis unavailable (Sun 05
Jun 2022 05:43:34 PM EDT)
Of course I do not have an example from when it used to work just
fine. All I can assume now is that something else I upgraded early
last week is causing a problem, but I won't be surprised if I'm
surprised at how stupid the problem is, once I find it.
Update later today.
Jack
On 6/7/22 13:54, Albrecht Dreß via balsa-list wrote:
Hi Jack!
Am 05.06.22 23:54 schrieb(en) Jack Ostroff via balsa-list:
** (balsa:8879): DEBUG: 17:43:34.702: Networkis unavailable (Sun
05 Jun 2022 05:43:34 PM EDT)
That message is printed by function print_network_status() in
src/main-window.c. Balsa uses a GNetworkMonitor (returned by
calling g_network_monitor_get_default()) to check if the network is
available or not. If you see this message only /once/, it is most
like being emitted from balsa_window_init() (in the same source
file) using the return value of calling
g_network_monitor_get_network_available(). The docs say
<quote>
Checks if the network is available. "Available" here means that the
system has a default route available for at least one of IPv4 or
IPv6. It does not necessarily imply that the public Internet is
reachable.
</quote>
We connect to the “network-changed” of the monitor, which should
print a similar message whenever the network state changes.
but I have no idea if this really indicates some network problem
or is just a red herring (false lead) as balsa is able to send
messages by smtp. Next step will be to debug and look for a
backtrace from the place that message is printed.
In libbalsa/server.c (libbalsa_server_test_can_reach*) we have
additional functions for checking if a remote server is reachable,
which internally call g_network_monitor_can_reach_async() and
g_network_monitor_can_reach_finish(). I can only guess that there
/might/ be an issue with your network or the gio configuration.
SMTP may work if you use a local MTA (localhost or 127.0.0.1) as
that address should always be reachable.
Best, Albrecht.
_______________________________________________
balsa-list mailing list
balsa-list gnome org
https://mail.gnome.org/mailman/listinfo/balsa-list
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]