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.
On Thu, Apr 11, 2013 at 4:16 PM, Natanael Olaiz <nol...@gmail.com> wrote: > Ooops, I sent it by error without finishing it... sorry. > > > After some cleanup on both machines KDM is working again! > > The cleanup consisted in: > - revdep-rebuild > - python-updater > - perl-cleaner > - an upgrade of the few new outdated packages > > I triggered all the commands in chain this morning and I see now that is > working without knowing what was the problem. > I only see on /var/log/portage/elog on one of the machines that > kdelibs-4.10.2 was reinstalled (I guess by revdep-rebuild, there was no > upgrade for kdelibs), but as far I see it was not reinstalled in the > other... > > > Anyway, the same chain on both systems solved the problem. > > > Do you know any other file I can use to backtrace the cleanup command's > actions? I cannot found more useful logs, and I lost the console buffer. > > > Can you try them? > > > Best regards, > Natanael. > > > > El 04/11/2013 10:00 PM, Natanael Olaiz escribió: > > > > > > > On 04/10/2013 10:28 PM, Natanael Olaiz wrote: > > I forgot: I'm using sysvinit, and policykit is enabled for kdelibs. > > So I also tried reinstalling consolekit and polkit (the day I tried I > had to patch polkit 0.110 in order to compile !!! :-/). Nothing changed. > > > Natanael. > > > On 04/10/2013 10:11 PM, nael wrote: > > Hi, > > On 04/09/2013 05:05 PM, Yuri K. Shatroff wrote: > > On 09.04.2013 17:13, João Matos wrote: > > 2013/4/9 Yuri K. Shatroff <yks-...@yandex.ru <mailto:yks-...@yandex.ru> > <yks-...@yandex.ru>> > > Hello gentoo-users, > > Yesterday I completed a world update (amd64, unstable) and now I > can't login with kdm. > (I have kdm set as display manager in /etc/conf.d/xdm, and started > from default runlevel) > After booting, the login screen appears as usual. I type > login/password and then a glimpse of X's default x-shaped pointer on > black background appears, returning to the login screen. > I don't get any sensible errors, neither in kdm.log nor in messages, > all I see is: > > [/var/log/kdm.log] > ----------------------------- > klauncher(21958) kdemain: No DBUS session-bus found. Check if you > have started the DBUS server. > kdeinit4: Communication error with launcher. Exiting! > kdmgreet(21952)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned > initialize() D-Bus call failed: "Not connected to D-Bus server" > > kdmgreet(21952)/kdecore (K*TimeZone*): No time zone information > obtained from ktimezoned > ----------------------------- > > But I guess this is unrelated, since dbus is running (and restarting > it doesn't help, nor does restarting xdm) > > Each time login fails I also see this in > [/var/log/messages] > ----------------------------- > Apr 9 11:33:53 localhost kdm: :0[20396]: pam_unix(kde:session): > session opened for user yks by (uid=0) > Apr 9 11:33:54 localhost kdm: :0[20396]: pam_unix(kde:session): > session closed for user yks > ----------------------------- > > No other logs appear to change. > > Needless to say that kdm 4.10.1 and earlier worked properly, and no > configuration files were changed during the last update. > > As a workaround, I just typed startx on the console (with startkde > in .xinitrc) and KDE started up, so I assume the problem is > somewhere around kdm. > > I' m exactly in the same situation. In two different machines I had the > same result upgrading world. The upgrade included kde 4.10.2, but I also > udev-201 and more ebuilds. > > On one of the machines I tried downgrading udev but didn' t work. > > > Xdm doesn't work neither, but gdm does! > startx with "startkde" also works. > > > Did you found something more? > > > > Best regards, > Natanael. > > > > Any ideas? > > P.S. I had no problem with networking and udev which got updated > from 197-r9 to 200 and the network interface name didn't change from > eth0 (the 80-*rules file was a regular file full of commented text) > > -- > Best wishes, > Yuri K. Shatroff > > > Hi. I have a similar problem here, since the last update from kde 4.9. > But I can login with my user, I just cant using any new user. I found > this problem easily, because I have a guest account, and I erase > "/home/guest/*" once in a while. Since two months ago this account is > useless. > > that's a little different problem ;) I remember the related discussion > on this mailing list. > > > But my kde is istill 4.10.1. It seemed nobody had the same problem, and > my problem was not that bad because my own account was working pretty > well. > > The error is exactly the same of yours, when I try to login the guest > account, but when I try "startx" a get the following: > > /etc/X11/xinit/xinitrc line 63: exec: xterm: not found > > Can this be solved by putting an executable .xinitrc into the user's > home dir? > As for me, I had to put > ----- > exec /usr/bin/startkde > ----- > so that startx would start kde. > > > I don't think it will help, because I get the same error if I try the > "working account". > > I'm using systemd, so I tried to remove consolkit support from kdm, but > it didn't help. > > I also have a suspicion it has to do with consolekit, but there is no > simple way to make sure. > > > Is anyone else facing a similar problem? > > > -- > João de Matos > Linux User #461527 > Graduado em Engenharia de Computação > UEFS - Universidade Estadual de Feira de Santana > > > >
