This has been an ongoing problem for several versions, the only fix which seems to work and will hopefully work permanently will be to make it depend on utempter instead of libutempter. I have included ebuilds for both kdelibs and xterm since xterm also depends on libutempter. After emerging both everything works. It's necessary to unmerge libutempter before trying to emerge these ebuilds. Hopefully these changes can be integrated into the portage tree. Reproducible: Always
Created attachment 167396 [details] ebuilds for overlay
One word of warning, although you will have a working kwrited daemon with wall messaging functional on your desktop, you will need to revdep-rebuild and many packages will need to be recompiled, most of kde 3.5 and 4.1.2 . I would use these ebuilds only if you truly need this functionality.
Don't use this as of yet, it was working perfect until reboot, now it seems to be having some problems, I will report back.
Unfortunately, this doesn't work because kde4 does work with libutempter, what is needed is a proper patch for kdelibs 3.5.10 to make it work with libutempter.
Okay, now something even more interesting. Using the current version of kdelibs-3.5.10, if libutempter is emerged and then you logout and login, wall messaging will work.
Okay, I have found the problem, it's with the permissions that wtmp and utmp run, by setting chmod 664 /var/log/wtmp && chmod 664 /var/run/utmp prior to login, it works. What I did was set this in /etc/conf.d/local like this # Here is where you can put anything you need to start # that there is not an init script for. local_start() { # This is a good place to load any misc programs # on startup (use &>/dev/null to hide output) chmod 664 /var/log/wtmp && chmod 664 /var/run/utmp # We should always return 0 return 0 } local_stop() { # This is a good place to unload any misc. # programs you started above. # We should always return 0 return 0 } This needs to be fixed elsewhere, not exactly sure where or how.
Permissions for wtmp and utmp seem to come from /etc/init.d/bootmisc which is part of sys-apps/openrc-0.2.5 on my ~x86 system at least. So this whole issue is probably more an OpenRC issue than a KDE issue.
My /var/log/wtmp file has 644 permssions with root:utmp owner and group. Also, I can see on /etc/init.d/bootmisc, line 83 the following snippet: chmod 0644 /var/run/utmp /var/log/wtmp How is openrc causing this?
I am looking at where wtmp & utmp are created in bootmisc, for whatever reason although the init script tells it to create with 644 permissions, they are not when it completes booting. if dir_writeable /var/run; then ebegin "Creating user login records" cp /dev/null /var/run/utmp if dir_writeable /var/log; then logw=true [ -e /var/log/wtmp ] || cp /dev/null /var/log/wtmp chmod 0644 /var/run/utmp /var/log/wtmp fi eend 0 ebegin "Cleaning /var/run" for x in $(find /var/run ! -type d ! -name utmp \ ! -name random-seed ! -name dev.db \ ! -name ld-elf.so.hints ! -name ld.so.hints); do [ ! -f "${x}" ] && continue # Do not remove pidfiles of already running daemons case "${x}" in *.pid) start-stop-daemon --test --quiet \ --stop --pidfile "${x}" && continue ;; esac rm -f -- "${x}" done eend 0
Jorge, (and BTW, Great job with the kde 4.1.2 ebuilds!!), try it on your system on kde 3.5.10, for whatever reason it works out of the box on kde 4.1.2 regardless of permissions. See what the permissions are of wtmp and utmp prior to login.
(In reply to comment #8) > My /var/log/wtmp file has 644 permssions with root:utmp owner and group. Also, > I can see on /etc/init.d/bootmisc, line 83 the following snippet: > chmod 0644 /var/run/utmp /var/log/wtmp > How is openrc causing this? libutempter allows applications to add utmp records even when they run as unprivileged users. It works by calling the utempter binary, which on my system looks like this: -rwxr-s--x 1 root utmp 6504 26. Feb 2007 /usr/lib/misc/utempter/utempter So it is only sgid utmp, not suid root. Therefore it seems a sensible requirement that utmp and wtmp would need to belong to group utmp and be writable by that group. That's what I thought when reading comment #6, which talks about mode 664. If Mode 644 or a group other than utmp solve the problem as well, as later comments seem to suggest, then it is beyond me how they do it. Maybe they modified wtmp as root through some other mechanism, not using utempter at all? I'm working remotely atm, so I can't experiment myself right now.
I read the init script for bootmisc after you mentioned this Martin and it would appear that utmp and wtmp get created with the right permissions on boot but my guess is that something somehow changes the permissions after they are created. That's the reason why by modifying it again in local which is the very last init script to run, the permissions remain correct and wall works. What I dont understand is why kde 4.1.2 works regardless of permissions and why 3.5.10 doesn't.
(In reply to comment #12) > I read the init script for bootmisc after you mentioned this Martin and it > would appear that utmp and wtmp get created with the right permissions on boot > but my guess is that something somehow changes the permissions after they are > created. That's the reason why by modifying it again in local which is the > very last init script to run, the permissions remain correct and wall works. I don't understand. On my system, bootmisc uses 644 while I argued that 664 should be the correct mode. Why do you say that bootmisc does create the files with the right permissions? I can imagine three possible reasons: 1. Have you modified your bootmisc from what's installed by the openrc ebuild? 2. Have you changed your mind, and now consider 644 correct enough? 3. Have you simply overlooked that one digit difference? > What I > dont understand is why kde 4.1.2 works regardless of permissions and why > 3.5.10 doesn't. Possible reasons I can think of: 1. You start your kde 4.1.2 session in some different way that your 3.5.10 session, so that some privileged process can write the utmp record. I guess one could rule this out by starting X from the command line, like this: XSESSION=kde-4.1 startx -- :1 2. KDE 4 could be using some method other than libutempter. Looking at http://websvn.kde.org/trunk/KDE/kdelibs/kpty/kpty.cpp?view=markup I see that there are some alternatives in place, most notably this utmpx stuff. I don't know if that involves some unprivileged access to wtmp, but it might. On the other hand, when utempter is configured, utmpx wouldn't get compiled in. To make sure, one could try to build a version of the utempter binary which does some logging. By passing CFLAGS=-DUTEMPTER_DEBUG, one could build an utempter with debugging output to stderr, but syslog would be more useful when debugging kde login mechanisms, so you'd have to edit the sources. 3. Maybe there isn't even a wtmp record for KDE 4, but kwrited has some other means to get at wall messages. I could imagine dbus playing a part there. Just guessing, but checking the output of "who" might be useful, to see whether writed registered a pty or not.
Martin, I'm sorry, you are absolutely correct!! Bootmisc creates utmp with 644 and not 664, that detail slipped past me!!
Martin, I'm glad you caught that, I have tested by modifying bootmisc to 664 and it works perfect. Filing a bug against openrc and closing this one as the real problem is with openrc!!
Opened bug here http://bugs.gentoo.org/show_bug.cgi?id=240437
