I have freshly installed net-misc/netkit-talk v0.17-r2 fine with no problems. Happily I have updated my xinetd.conf, restarted xinetd, but talk says "Error on read from talk daemon: Connection refused". So I tried `talkd -dp` which gives me the error "Socket operation on non-socket". This is the strace for the developers, which might help to find the error: ---schnippp--- execve("/usr/sbin/talkd", ["talkd", "-dp"], [/* 32 vars */]) = 0 brk(0) = 0x804b540 open("/etc/ld.so.preload", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 close(3) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=34515, ...}) = 0 old_mmap(NULL, 34515, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\201"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1335670, ...}) = 0 old_mmap(NULL, 1191040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000 mprotect(0x40136000, 40064, PROT_NONE) = 0 old_mmap(0x40136000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x118000) = 0x40136000 old_mmap(0x4013c000, 15488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4013c000 close(3) = 0 munmap(0x40014000, 34515) = 0 getsockname(0, 0xbffff9c0, [16]) = -1 ENOTSOCK (Socket operation on non-socket) write(2, "Socket operation on non-socket", 30Socket operation on non-socket) = 30 _exit(1) ---schnapp--- from information from the internet I changed /etc/services to: ---schnipp--- talk 517/udp talk 517/tcp ntalk 518/udp ntalk 518/tcp ---schnapp--- and also have set /etc/host.conf to: ---schnipp--- order hosts,bind multi on ---schnapp--- and /etc/hosts to have all the names for the eth0 ip and nothing for the eth1, which is my default route interface. nothing helped. /lib/libc.so.6 is a symbolic link to libc.2.2.5.so and as /etc/ld.so.preload is empty and /etc/ld.so.conf was ---schnipp--- /usr/local/lib /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2 /usr/lib/opengl/xfree/lib /usr/X11R6/lib /opt/blackdown-jdk-1.3.1/jre/lib/i386/ /opt/blackdown-jdk-1.3.1/jre/lib/i386/native_threads/ /usr/qt/2/lib ---schnapp--- I changed /etc/env.d/00basic to have LDPATH=/lib:/usr/lib:/usr/local/lib and env-updated and reinstalled, but there was no change, either. so, I don't know what else to do, maybe you can help. If you need further information, feel free to ask. Mind that I am no c-programmer. thanx Sascha
The connection refused message means that xinetd is not recognising your talkd entry. Make sure your entry for talkd agress with reality. You may want to look at your syslog to see what xinetd thinks of your talkd entry.
Hi Bryon, thanx for the advice. I double checked the xinetd.conf by a lot of examples from the internet and prooved it errorfree. but as it does not work, although it gives no errors to the syslog, I checked the situation on another system, which is running talkd functionally with inetd. coming from that, here is my solution: # ln -s /usr/sbin/talkd /usr/sbin/in.ntalk /etc/xinetd.d/talkd ---schnipp--- service talk { disable = no socket_type = dgram wait = yes user = nobody group = tty server = /usr/sbin/in.talkd server_args = -pd } ---schnapp--- /etc/xinetd.d/ntalkd ---schnipp--- service ntalk { disable = no socket_type = dgram wait = yes user = nobody group = tty server = /usr/sbin/in.ntalkd server_args = -pd } ---schnapp--- apparently netkit-talk misses to link talkd to in.ntalkd which it does with in.talkd. an inetd.conf starts two services, talk and ntalk. so I did. and it works, now! If my computer is an isle in the ocean of gentoo users using xinetd having had a talk problem, which all the others don't have, close the bug for the records. If this is not so, update the portage files (including information for xinetd, which comes with no further information about that), please! one last problem: short tests showed talk working, but syslog told: "/var/log/talkd.log: No such file or directory" and "/var/log/talkd.packets: No such file or directory" touching them, chowning them to nobody.tty and chmod a+w stops that errormessage, but they keep being empty. can you verify that? sincerly Sascha
sorry -- have been busy. if you want to show me a patch here, which i can apply to something that will fix your talkd problem, please do otherwise this might tend to keep taking a back seat. as for your logs, not sure.. i havent used talk in quite some time.
Hi Donny, don't mind about having been busy, that's human, so no excuse is nescessary. Sorry that I am no C/C++ developer, nor an emerge-builder, yet. So I can't afford you with a patch... The cause is simple: Just verify what I said in my last post, when you have the time. I am "talking" a lot, since doing so! Have a good new year, greetings, Sascha
hm, I can't reproduce the missing symlink. if I install netkit-talk-0.17-r2 I get the proper symlink from talkd to in.talkd. as for the syslog issue, I'm not quite sure what to do about that, since Gentoo provides different loggers and they can be set up to use those files, or not. maybe we should just produce some information in the last part of the ebuild regarding loggers? testing what logger someone uses and then creating the logfiles that might work isn't a good solution, IMHO. something like this? pkg_postinst { einfo "please make sure that talkd and your logger talk together"; einfo "you might also need to restart / reload your logger"; } for the logger restart comment, I've seen this somewhere but I can't remember where. it doesn't hurt though. Sascha, can you restart your loggers and confirm that the files are still empty? and if they are, can you see if anything gets logged to any other logfile? /etc/syslog.conf can also give some hints towards a fix.
In between current status is: - talkd works fine, - /var/log/talkd.log logs fine, - /var/log/talkd.packets logs none. To correct your last assumption, it was in.ntalkd which was not symlinked, not in.talkd which was symlinked correctly. And the xinetd.conf, like the inetd.conf needs two deamons to get talk working correctly, in.ntalkd and in.talkd! Next the logger thing. From the very first start, when the in.ntalkd problem was solved, talkd _was_ messaging to the logger, because it said "/var/log/talkd.log: No such file or directory" and "/var/log/talkd.packets: No such file or directory" So there is no problem with messaging to the logger but the nonexistent files, which can't be created, for what reason of I don't know. This is the first problem, which I could resolve. Creating them and chowning them to the user as configured at the xinetd/inetd.conf fixed that problem and /var/log/talkd.log was logging talkd sessions information from that on (sooner or later, I can't remember to have changed anything for that) The /var/log/talkd.packets keep being empty: The talkd man page says so and I configured xinetd.conf to have the command switch -dp, where -p should enable Packet logging mode, but it doesn't. This is the second left problem left, which I could not resolve. Work to be done: ---------------- For the bugfix: - find why the in.ntalkd symlink isn't created and fix it. - find why the logfiles can't be created and fix it. For the documentation: - nothing espessially, but an example of inetd.conf and the more popular becoming xinetd would be fine at a /usr/share/doc/talkd-version/README.gz file would be fine, see comment #2 greetings, Sascha
I just canot manage to set aside time to look at this! Arrrrgh!
talk daemon stuff should only be udp if i'm not mistaken... so the tcp entries in /etc/services are not needed... currently testing on my dev machine right now.
netkit-talk-0.17-r4 emerges fine, installs an appropriate xinetd file, etc... No changes should be required to ANY files other than enabling the xinetd.d/talk entry so the daemon starts properly :) Please test this build.
this issues doesn't seem to be relevant in the latest -r4 which is now marked stable for x86. Closing bug.
