On 12.04.2013 00:35, Forrest Schultz wrote:
To be fair, I really don't know much about either of these processes.
However, it looked like the log was describing a situation where, due to
a lack of timezone information, the two processes were unable to
communicate properly. Is it at all possible that this is caused by some
processes defaulting to different time zones? DBUS certainly sounds like
a program where correct time information would be important. On the
other hand, I would think that they would both pull system time if that
was the case. Also, none of things you did sound like they would have
fixed that. It also seems possible that the library/package rebuild
fixed something that was wrong with ktimezoned specifically. Well,
there's my two cents.
The problem is gone after another sync and world-update, which also
affected kdelibs (due to png update) and udev 200->201. So, it wasn't
possible to identify the problem's source. Just hoping it will not
appear again to anyone.
Anyway, thanks for your opinion.
Regarding ktimezoned:
there is no problem with it, and I'm still getting the same messages
even now that everything is in order.
if you look at the log I supplied, you see the first message is
klauncher(21958) kdemain: No DBUS session-bus found. Check if you
have started the DBUS server.
The message regarding ktimezoned also states:
ktimezoned initialize() D-Bus call failed: "Not connected to D-Bus server"
But dbus is up and running:
# rc-service dbus status
* status: started
I don't know why this happens, maybe there's a dependency issue in
OpenRC which allows xdm service to start before dbus, but as long as it
doesn't hamper my system, I'd close my eyes on it. [OT] In general, I
don't see any point in KDE's specific services such as ktimezoned,
because they seem to me nothing but memory-eaters possibly doing the job
already done by kernel and system tools (and more probably, doing no job
at all).
--
Best wishes,
Yuri K. Shatroff
