Adding to the discussion of beachballing:
I updated my OS X server to 10.3.9 over the weekend. It runs the DNS
server. And the DNS Server works fine for web, ssh, afp etc. It also
works some time for PM, meaning that connecting via POP to external mail
servers work as before. However, at some time running, PM takes forever
to connect to the external mail servers: O get no display (yet) in the
background processes window, but PM beachballs for about 2 to 5 minutes
before starting retrieving email.
I did a Sample on PM when this happens, and the prominent trace is:
Analysis of sampling pid 409 every 10.000000 milliseconds
Call graph:
92 Thread_110b
92 start
92 _start
92 main
92 LApplication::Run()
92 CPMApp::ProcessNextEvent()
92 LTSMDocApp::ProcessNextEvent()
92 LEventDispatcher::UseIdleTime(EventRecord const&)
92 LPeriodical::DevoteTimeToIdlers(EventRecord const&)
92 CPMApp::SpendTime(EventRecord const&)
92 CPMApp::SchedulingIdle()
92 CPMApp::SchedulingIdleCallback(void*, void*)
92 CMAS::SchedulingIdle()
92 CRemoteNetworkServicesImp::IsConnected()
const
92 gethostbyaddr
92 gethostbyaddrerrno
92 lu_gethostbyaddr
92 _lookup_all
92 _lookup_all_secure
92 mach_msg
92 mach_msg_trap
92 mach_msg_trap
The problem is intermittent with no action on my part; if the problem is
there, restarting PM does not help. After some 15 minutes, the problem
vanishes on its own for some time, then re-occurs. During the
beachballing, Interarchy shows outgoing connections to my POP servers
being created, slowly (a change very 15 seconds or so). The DNS server
log (named.log) on my OS X Server says for one of my POP servers the
following (this log was created while the beachballing situation occurred):
Jun 06 13:27:15.907 createfetch: mx.freenet.de A
Jun 06 13:27:15.944 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:15.946 message has 2 byte(s) of trailing garbage
Jun 06 13:27:16.399 createfetch: 20.64.165.213.in-addr.arpa PTR
Jun 06 13:27:16.401 message has 4 byte(s) of trailing garbage
Jun 06 13:27:20.948 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:20.949 message has 2 byte(s) of trailing garbage
Jun 06 13:27:25.950 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:25.952 message has 2 byte(s) of trailing garbage
Jun 06 13:27:30.954 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:30.955 message has 2 byte(s) of trailing garbage
Jun 06 13:27:36.108 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:36.109 message has 2 byte(s) of trailing garbage
Jun 06 13:27:36.656 createfetch: 144.50.97.194.in-addr.arpa PTR
Jun 06 13:27:36.658 message has 2 byte(s) of trailing garbage
Jun 06 13:27:41.110 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:41.112 message has 2 byte(s) of trailing garbage
Jun 06 13:27:46.114 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:46.115 message has 2 byte(s) of trailing garbage
Jun 06 13:27:50.493 createfetch: 2.96.201.81.in-addr.arpa PTR
Jun 06 13:27:50.495 message has 3 byte(s) of trailing garbage
Jun 06 13:27:51.116 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:51.118 message has 2 byte(s) of trailing garbage
Jun 06 13:27:56.143 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:27:56.144 message has 2 byte(s) of trailing garbage
Jun 06 13:28:01.145 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:01.146 message has 2 byte(s) of trailing garbage
Jun 06 13:28:06.147 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:06.149 message has 2 byte(s) of trailing garbage
Jun 06 13:28:11.149 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:11.151 message has 2 byte(s) of trailing garbage
Jun 06 13:28:16.201 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:16.203 message has 2 byte(s) of trailing garbage
Jun 06 13:28:21.214 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:21.216 message has 2 byte(s) of trailing garbage
Jun 06 13:28:24.236 createfetch: 20.64.165.213.in-addr.arpa PTR
Jun 06 13:28:24.238 message has 4 byte(s) of trailing garbage
Jun 06 13:28:26.217 createfetch: 25.52.30.128.in-addr.arpa PTR
Jun 06 13:28:26.218 message has 2 byte(s) of trailing garbage
[...]
Any clue what this problem might be? Is this an issue with my 10.3.9 DNS
implementation? Or a problem with PM that only shows with some change in
the 10.3.9 DNS? Or a result of the new 5.3 technique to detect when the
net is up?
Regards
Christian
