I haven't been able to get the KDE kwrited to work with wall or write in any Mandrake release past 9.1. I'm running 9.1 at home and it works fine. I get get alerts just fine in KDE from apcupsd in the event of power outages.

I've noticed that, starting in 9.2, the /dev/pts/* devices belong to my own users default group rather than tty. I saw a post recommending that this be changed in /etc/devfsd.conf:

# Uncomment the following if you want to set the group to "tty" for the
# pseudo-tty devices. This is necessary so that mesg(1) can later be used to
# enable/disable talk requests and wall(1) messages.
REGISTER ^pty/s.* PERMISSIONS -1.tty 0600
#REGISTER ^pts/.* PERMISSIONS -1.tty 0600

Uncommenting that second line doesn't seem to work. After reboot, my /dev/pts/0 still belongs to my group. I'm not sure if that would address the problem anyway.

Also, while I understand the 'mesg y' command, I'm unclear how it relates to the DM or KDE. Is there a setting in the DM somewhere that enables write for that login?

The other unusual thing I've noticed is this: In 9.1, when a user is logged into X, the 'who' command shows two entries, one for pts/0 and one for the display :0. In 9.2 it shows only the entry for :0. In 10.0 it shows nothing at all....that one really doesn't seem right. Even if all permissions and everything were correct, write and/or wall won't work if it doesn't see the user logged in.

Any suggestions would be appreciated. Thanks!

Tom

My mistake on that issue with 'who'. In 9.2 there's an entry for display :0...the entry for /dev/pts/0 was from a telnet login and had nothing to do with this.

It is strange though that loggin into KDE in 10.0 doesn't seem to get writen to wtmp.

Tom

In trying to figure this out, I've discovered a few interesting things...

First of all, it appears that kwrited works ok...it listens to /dev/pst/0 (or whatever pts device the X session gets). If I log in as root and try:

echo testing > /dev/pts/0

...writed displays the message just fine.

The big problem does appear to be that, in 9.2 and 10.0, the pts device for the X session never gets into utmp. In 9.1 and prior it did. I can't figure out where this actually occurs in the older releases. The entry doesn't appear until the KDE is completely up and running.

In 9.2/10.0, without the sessions pst/* entered in utmp wall never finds it. Anyone have any idea if this can be configured somewhere??

Another potential issue is the group ownership of the device. Changing this line in /etc/fstab:

none /dev/pts devpts mode=0620 0 0
...to...
none /dev/pts devpts mode=0620,gid=5 0 0

...takes care of that, assigning /dev/pts/* to the tty group.

Here's the strangest thing I found: The default entries in the config file /usr/share/config/kdm/kdmrc used to define 'Startup' as /etc/X11/xdm/GiveConsole and 'Reset' as /etc/X11/xdm/TakeConsole. Since 9.2, these have been reversed. This adds display :0 for your user name when you log out of KDE.

Strange stuff. Anyway, if anyone has some idea where in the kdm and/or KDE login process the /dev/pts/0 would get added to utmp I'd like to know.

Tom

Hi,

answering to you just to thanks for the gid=5 trick wich enable "talk" for me again. I could make it work wifhout even rebooting thanks to "mount -o remount /dev/pts" after the change.

I could not answer to the other question, but to confirm that under gnome the behaviour is the same (i.e., no utmp entry for the /dev/pts/0 device).

Thanks again,
Romano

Thanks for the reply. I think I now know what the issue is. kwrited grabs the pts device (/dev/pts/0 or whichever) and listens to that device, but doesn't add the pts device to utmp unless it's been compiled with utemper support.

As a result commands such as wall never find it. Apparently people have had similar issues with Debian. I get the impression that utemper is viewed by many developers as a bit of a hack, and they simply don't want to use it.

Tom