Bug 737219 - Provide native systemd service files
Provide native systemd service files
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: talk (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vitezslav Crhonek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
 
Reported: 2011-09-09 21:08 EDT by Jóhann B. Guðmundsson
Modified: 2013-05-24 16:47 EDT (History)
5 users (show)

See Also:
Fixed In Version: talk-0.17-42.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-24 16:47:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
talk socket (166 bytes, text/plain)
2011-09-09 21:10 EDT, Jóhann B. Guðmundsson
no flags Details
talk service (136 bytes, text/plain)
2011-09-09 21:10 EDT, Jóhann B. Guðmundsson
no flags Details
ntalk socket (168 bytes, application/octet-stream)
2011-09-09 21:11 EDT, Jóhann B. Guðmundsson
no flags Details
ntalk service (138 bytes, application/octet-stream)
2011-09-09 21:12 EDT, Jóhann B. Guðmundsson
no flags Details
Updated [n]talk.service (213 bytes, text/plain)
2013-04-26 11:13 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details
Updated ntalk.socket (161 bytes, text/plain)
2013-04-26 11:14 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details
Updated [n]talk.service (204 bytes, text/plain)
2013-04-26 11:25 EDT, Zbigniew Jędrzejewski-Szmek
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2011-09-09 21:08:50 EDT
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:
Comment 1 Jóhann B. Guðmundsson 2011-09-09 21:10:06 EDT
Created attachment 522452 [details]
talk socket
Comment 2 Jóhann B. Guðmundsson 2011-09-09 21:10:55 EDT
Created attachment 522453 [details]
talk service
Comment 3 Jóhann B. Guðmundsson 2011-09-09 21:11:46 EDT
Created attachment 522454 [details]
ntalk socket
Comment 4 Jóhann B. Guðmundsson 2011-09-09 21:12:33 EDT
Created attachment 522455 [details]
ntalk service
Comment 5 Jóhann B. Guðmundsson 2011-09-12 19:20:33 EDT
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
Comment 6 Vitezslav Crhonek 2011-09-14 10:26:41 EDT
Did you test them? I'm not able to start the service using it...
Comment 7 Thomas H.P. Andersen 2012-12-04 17:38:40 EST
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)
Comment 8 Jóhann B. Guðmundsson 2012-12-04 20:24:25 EST
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
Comment 9 Thomas H.P. Andersen 2012-12-05 03:10:29 EST
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.
Comment 10 Fedora End Of Life 2013-04-03 15:46:51 EDT
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
Comment 11 Zbigniew Jędrzejewski-Szmek 2013-04-26 11:13:30 EDT
Created attachment 740453 [details]
Updated [n]talk.service
Comment 12 Zbigniew Jędrzejewski-Szmek 2013-04-26 11:14:44 EDT
Created attachment 740454 [details]
Updated ntalk.socket
Comment 13 Zbigniew Jędrzejewski-Szmek 2013-04-26 11:24:46 EDT
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?
Comment 14 Zbigniew Jędrzejewski-Szmek 2013-04-26 11:25:20 EDT
Created attachment 740465 [details]
Updated [n]talk.service
Comment 15 Zbigniew Jędrzejewski-Szmek 2013-04-30 15:36:18 EDT
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.
Comment 16 Jóhann B. Guðmundsson 2013-05-01 14:56:05 EDT
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?
Comment 17 Zbigniew Jędrzejewski-Szmek 2013-05-01 15:37:00 EDT
(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.
Comment 18 Jóhann B. Guðmundsson 2013-05-01 16:21:48 EDT
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
Comment 19 Fedora Update System 2013-05-02 11:59:07 EDT
talk-0.17-42.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/talk-0.17-42.fc19
Comment 20 Fedora Update System 2013-05-03 11:17:29 EDT
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).
Comment 21 Fedora Update System 2013-05-24 16:47:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.