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