Version: (using KDE KDE 3.4.2) Installed from: Compiled From Sources Compiler: GCC - 3.4.3 GLIBC - 2.3.3 OS: Linux Good Day, I'm in the process of upgrading my KDE system to 3.4.2 I'm using the Konstruct method to do this Upgrade. I have so far installed KDElibs, KDEbase and KDEpim When doing some testing, I found that the "kwrited" program does not appear to be working. When a "wall" command is entered from another User on my System while I'm using KDE, I do not get the Window on the Screen with the Wall message as I expected. I have checked the following components that are related to "kwrited" but I can't see any obvious errors: 1. in the KDE Control Center, under Service Manager, in the Starting Services area, the KDE Write Daemon box is checked and the Status says "Running" 2. At KDE Startup, I see the following message in the Log: kded: Successfully loaded module 'kwrited' 3. At the end of running KDE, I see the following message in the Log: KWrited - Listening on Device /dev/pts/0 4. In /proc/filesystems, it shows devpts 5. In "/dev/pts", everthing looks Valid 6. The "utempter" on my system is 0.5.5 7. The /usr/sbin/utempter program is -rwxr-sr-x root root 8. Environment A. Hardware - Pentium 4, 256Mb Ram B. Distribution - Caldera 2.3 C. Kernel - Linux 2.6.9 D. XFree86 - 4.4.0 Any information that someone could supply to me to get this problem resolved would be greatly appreciated. Yours truly, Frank Krauss
I just tried this on KDE 3.5 (I don't think kwrited has changed from 3.4.2). The user 'walling' has to have permissions to the /dev/pts/0. For example: crw--w---- 1 kvh tty 136, 0 Sep 18 19:24 /dev/pts/0 If the user kde4 issues % wall "hello" nothing happens due to invalid permissions (ie not of group tty).
Good Day all, I will try to give a better description of my Problem and why I think it has to do with KDE. I have, for example, two General Users, User1 and User2. 1. User1 is where I would be running KDE in. 2. User2 is where I will be issuing the "wall" command from. Results: 1. If I do NOT have KDE running in User1 and I issue a "wall" command from User2, the output of the "wall" comand comes up perfect in User1. 2. If I DO have KDE running in User1 and a "wall" command is issued from User2, I hear a Beep but I do NOT get any window with the Wall message on KDE as I should. I have tried all the things I can think off concerning permissions and proper Groups, such as: 1. Putting both User1 and User2 into the tty group in /etc/group 2. Setting the group of /usr/sbin/utempter to "tty" but none of them fix the problem. The /usr/bin/wall command itself is in the "tty" group. A "ls -l /dev/pts/0" command gives the following output: "crw--w---- 1 User1 tty 136, 0 Date /dev/pts/0" If there is any other information I can supply to someone to help me get "kwrited" to work on my system, I will be glad to provide it. If there is any kind of KDE tracing that someone would want me to do, I will be happy to follow their directions to debug this problem. Yours truly, Frank Krauss
Good Day everyone, Is there anyone who can give me any pointers on how to solve this problem? I still can't get any wall messages to come up on KDE 3.4.2. The Problem is completly re-createable and I can do any testing that someone would ask me to do. Thanking anyone who can give me a hand with this problem. Frank Krauss
I am also experiencing this bug with KDE 3.4.2 (on Slackware 10.2). I've done a little digging, and the problem seems to lie in kdelibs/kdecore/ktpy.cpp, specifically KPty::login and KPty::logout. I'd say those two functions need rewriting to use utempter_add_record and utempter_remove_record. I would guess that this has been broken ever since the new utempter API was introduced. Meanwhile, I have developed a workaround. Simply rename /usr/sbin/utempter to /usr/sbin/utempter.real and replace it with the attached script, chmod'd 0755.
Here's the workaround, it doesn't seem to want to attach... ---8<---cut-here---8<--- #! /bin/sh UTEMPTER=/usr/sbin/utempter.real case $1 in -a) exec $UTEMPTER add ;; -d) exec $UTEMPTER del ;; *) exec $UTEMPTER "$@" ;; esac ---8<---cut-here---8<---
Hello Ross, Thank you for giving me this idea to fix the problem. I will try it out this coming Week and tell you the results of my testing. If this works, it will be great for me since I can use badly the Wall command informing me of the status of my server while I'm running in KDE. Thank you again for this code. I hope you have a good weekend. Frank ------------------------------------------------------------- On Wednesday 26 April 2006 07:29 pm, Ross Axe wrote: [bugs.kde.org quoted mail]
I've tried this fix on a Mandriva 2006 system, which has utempter 0.5.5, and it looks like utempter will need upgrading to the latest version for my hack to work. It's available via http://freshmeat.net/projects/libutempter/. Meanwhile, if no patch for KDE is forthcoming, I will attempt to write one and post it here if I have any success.
Hello Ross, I just wish to tell you the results of my testing of your Code. I installed libutempter-1.1.3. The utempter program went into /usr/lib/utempter/utempter. I put your code into /usr/sbin/utempter. I modified UTEMPTER to point to /usr/lib/utempter/utempter. I then brought up KDE in a User Id and had a WALL command excuted from another Id. The results were unfortunately just what I have always received. I get a Beep when the WALL is executed but NO Window with the Wall data comes up. In order to try to debug this problem a bit, I reassembled utempter.c and added "#define UTEMPTER_DEBUG" to it. When I ran the test again, in the Console log, I'm getting the message: utempter: pututline: Bad file descriptor This is due to the failure of the pututline command on line 130 of utempter.c. As an additional piece of information for you, I have in my /etc/fstab the following statement: "none /dev/pts devpts mode=0620,gid=5 0 0" I had added this statement due to someone telling me once that they thought I needed that to get utemp to work. I tried the test both with this statement active and with it removed and I get the same bad results. I'm stumped for an answer to this problem. Any information you could give me to get this to work would be greatly appreciated. Yours truly, Frank
Using KDE 3.5.2/3 and utempter 0.5.5.6 comment #2 works for me.
Created attachment 17031 [details] Patch to kdelibs-3.5.3 to use libutempter "Old interface" The attached patch made things work for me using libutempter on Gentoo Linux. The config files already check for -lutempter and addToUtmp, so this is the function I'm using, although in my libutempter-1.1.4.1 include file this set of functions are marked as "Old interface". They simply forward the request to the new interface. But if we were to use the new interface directly, I'd suggest to check for utempter_add_record instead of addToUtmp. Opinions on this?
I also use Gentoo; a few weeks ago I removed utempter and installed libutempter. I wonder what other distro use? It is too late for KDE 3.5.4. http://bugs.gentoo.org/show_bug.cgi?id=135818
As configure checks for a library, I assumed that it would depend on libutempter. But I just checked that utempter-0.5.5.6 installs a libutempter.so as well, providing just the "old interface". Therefore my patch should work for this setup as well, and moving to the new, libutempter-only interface is probably not a good idea right now.
Marked as confirmed - Kurt, is this patch applicable to kdelibs 4 as well?
How come that my patch is still not included in the KDE 3.5.5 release? Any good reasons against it?
> How come that my patch is still not included in the KDE 3.5.5 release? Because nobody got around to reviewing and committing it. Thank-you for providing the patch, sometimes it is necessary to chase the developers up until it gets committed. You mentioned that the patch uses the "old interface". Is it possible to update it to use the "new interface" instead? I prefer not to write new code against deprecated interfaces if possible.
Created attachment 19544 [details] Patch to kdelibs-3.5.6 to use libutempter "New interface" > Is it possible to update it to use the "new interface" instead? Sure, but this would break compatibility with the old RedHat utempter implementation. As far as I can tell even Fedora Core has switched to libutempter, so I don't know whether there are any distros out there still using the old utempter. Neither do I know how long the compatibility interface is going to stay around in libutempter. Looking at the source code from libutempter 1.1.4 available at http://altlinux.org/index.php?module=sisyphus&package=libutempter you will see in iface.c how the wrappers are implemented. It boils down to this, already with the kdelibs arguments: Old interface: addToUtmp (d->ttyName, remotehost, d->masterFd); removeLineFromUtmp(d->ttyName, d->masterFd); New interface: utempter_add_record(d->masterFd, remotehost); utempter_remove_record(d->masterFd); As the new interface uses another function from the library, configure has to be modified as well. Is configure.in.in the correct file for this? My patch changed the symbol name there, seems to work all right. Of course, from the compatibility point of view it might be best to use configure to check for the new interface, and fall back on the old interface if that is available and the new one isn't. As the interfaces are similar enough, the impact on the source files would be minimal. But configure itself would have more work to do, I'll leave this to someone with at least a bit of experience with autotools.
See also related bug #140308
Bug #140308 seems to be the better place to continue this discussion. Maybe this bug here should become a duplicate of that? I also heard from the libutempter maintainer, Dmitry V. Levin, that the backward compatible interface is going to stay. So although it is deprecated because the new one is simpler, there is nothing wrong with using the old interface to keep compatibility to old utempter implementations. Therefore I'd rather use the patch from comment #10 instead of the one from comment #16.
This should be fixed now, provided that bug 140308 is also fixed. The patch is the same. *** This bug has been marked as a duplicate of bug 140308 ***