Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 522452 [details] talk socket
Created attachment 522453 [details] talk service
Created attachment 522454 [details] ntalk socket
Created attachment 522455 [details] ntalk service
Once package and shipped your package should no longer have to depend on xinetd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
Did you test them? I'm not able to start the service using it...
I have been debugging why these do not work. For whatever reason the problem seems to be with having both of these lines at the same time: ListenDatagram=[::]:517 ListenDatagram=0.0.0.0:517 When I start the socket and send some bogus data with "traceroute -p 517 localhost" systemd goes into an endless loop failing to start the service. It very quickly hits its own limit for retrying to start the service too often. Anyway. If only one of the lines is used, or simply "ListenDatagram=517" it works just fine. The way it was originally started with xinetd had the IPv4 flag so maybe "ListenDatagram=0.0.0.0:517" is the appropriate option? (and the equivalent with port 518 for ntalkd)
ntalk works just fine here with this socket file [Unit] Description=NTalk Server Activation Socket [Socket] Service=ntalk.service ListenDatagram=0.0.0.0:518 [Install] WantedBy=sockets.target But for the love of me I cant get talk to work I always get connection refused but feeding the port gibberish via netcat shows it is responding in debug mode Malformed packet (length 6) Probing for QUIRK_OTALK QUIRK_OTALK: wrong siz
I never got talk to work completely either. I also tried with debug mode for talkd but it just complained that it could not write to /var/log/talkd.log. Like you I can see the process is started and it complains about the malformed data I am feeding it. So something is not 100% right yet. However, I also failed to get talkd/ntalkd working with the old xinetd-way. I got some selinux errors.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Created attachment 740453 [details] Updated [n]talk.service
Created attachment 740454 [details] Updated ntalk.socket
I can confirm that the above ntalk.socket + ntalk.service work for me. I looked at the sources of talk, and it explicitly connects to the ntalk (==518) port. ytalk which is another client, prefers ntalk port, but falls but to the talk port. ntalk protocol appears to be from 1983 (courtesy of wikipedia), so I think we can drop port 517. I added Alias=talk.service, since most people don't know that the two are equivalent. Can we please apply those files and close this bug?
Created attachment 740465 [details] Updated [n]talk.service
Is there any reason why this can't be fixed in time for Fedora 19? It's one of the last ~10 uncoverted packages, and one of the simplest ones. Nobody wants to install xinetd just to have talk working.
It's allowed up to beta to package systemd units but after that the window is closed Where do you get that 10 number from?
(In reply to comment #16) > It's allowed up to beta to package systemd units but after that the window > is closed Right, we're at alpha now, so the time is ripe! > > Where do you get that 10 number from? Sysvinit2systemd has about 20 bugs still open, and maybe half are in ON_QA or such.
Ah I see I created different tracker for different releases so more accurate number that remains to be migrated is around 150 excluding around 30 cron jobs to migrate to timer units(In reply to comment #17) > (In reply to comment #16) > > It's allowed up to beta to package systemd units but after that the window > > is closed > Right, we're at alpha now, so the time is ripe! > > > > > Where do you get that 10 number from? > Sysvinit2systemd has about 20 bugs still open, and maybe half are in ON_QA > or such. Ah I see I created different tracker for different releases so more accurate number that remains to be migrated is around 150 excluding around 30 cron jobs to migrate to timer units
talk-0.17-42.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/talk-0.17-42.fc19
Package talk-0.17-42.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing talk-0.17-42.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7318/talk-0.17-42.fc19 then log in and leave karma (feedback).
talk-0.17-42.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.