Description of problem:
Let's get the ball rolling on this one...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 522446 [details]
Created attachment 522447 [details]
Passes simple telnet test and note there is still a (tight) window to have this
Created attachment 522449 [details]
new tftp socket
Created attachment 522450 [details]
new tftp service
Once package and shipped your package should no longer have to depend on xinetd
Created attachment 523278 [details]
Created attachment 523279 [details]
Manage to have time to properly test the unit files
Verbose mode on.
tftp> get my-test-file.txt
getting from 127.0.0.1:my-test-file.txt to my-test-file.txt [netascii]
Sep 14 23:37:47 localhost in.tftpd: RRQ from ::ffff:127.0.0.1 filename my-test-file.txt
Unit With debug
ExecStart=/usr/sbin/in.tftpd -v -v -s /var/lib/tftpboot
StandardOutput=socket #needed due to a bug in systemd .35 will be fixed in 36
There is report of both the xinetd and systemd version failing in an alias ip setup is that to be expected?
(In reply to comment #6)
> Once package and shipped your package should no longer have to depend on xinetd
Is there any Fedora's feature that obsoletes inetd?
None that I'm aware of should there be?
The move to systemd obsoletes the need for the components we ship on xinetd as it does obsolete the need for components we ship on port reserve ( which is why Tim is going to deprecate/drop the package) .
I personally have not look how well systemd replaces xinetd functionality other then to the extent of all the components we ship and it does indeed replace it there.
Honestly I suspect that systemd does not replace *all* of xinetd functionality and I would not be surprised that there might be 3 party out there depending on it as well so I'm not foreseeing xinetd itself being removed from the distribution any time soon however if or rather when that time comes then it would not be a more of an issue than simply dropping the xinetd package.
This is just part of the migration process as I see it and other distribution seem to be going down this path as well which is why I went ahead did what needed to be done and converted all xinetd dependend components to systemd units we have in Fedora.
When asking FPC if maintainers should package xinetd snippets in an separately subpackage as is being done with the legacy sysv init script I was flagged as being on somekind of crusade against xinetd.
If the governing body if the distribution want to have thing half migrated to systemd fine.
If governing body of the distribution want to be out of line with what other distributions are doing I'm fine with at also.
Since I got better things to do than wasting my time in doing work which needs to be done for the project which ends up either not being used or being appreciated and I and my work being ridiculed in the process have at it.
I personally wont be making such an proposal nor will I stand in your ( or any ones else for that matter ) way from you doing whatever you feel is right.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I can't get this working.
# systemctl start tftp.service
Job failed. See system logs and 'systemctl status' for details.
# systemctl status tftp.service
tftp.service - Tftp Server
Loaded: loaded (/lib/systemd/system/tftp.service; static)
And /var/log/messages contains:
systemd: tftp.service failed to run 'start' task: Invalid argument
Not sure if there is something that needs to be added or modified. Systemd has probably moved a long way since this bug was filed.
(In reply to comment #14)
> I can't get this working.
> # systemctl start tftp.service
> Job failed. See system logs and 'systemctl status' for details.
> # systemctl status tftp.service
> tftp.service - Tftp Server
> Loaded: loaded (/lib/systemd/system/tftp.service; static)
> Active: failed
> CGroup: name=systemd:/system/tftp.service
> And /var/log/messages contains:
> systemd: tftp.service failed to run 'start' task: Invalid argument
> Not sure if there is something that needs to be added or modified. Systemd
> has probably moved a long way since this bug was filed.
Try starting the socket not the service since the service is socket activated systemctl start tftpd.socket =)
Created attachment 586076 [details]
Created attachment 586077 [details]
I've updated the unit file as in removed stuff I put in there because of that bug and for stuff that is no longer necessary.
[root@localhost system]# systemctl start tftp.socket && systemctl status tftp.socket && tftp localhost -c status
tftp.socket - Tftp Server Activation Socket
Loaded: loaded (/etc/systemd/system/tftp.socket; disabled)
Active: active (listening) since Tue, 22 May 2012 16:27:16 +0000; 3min 32s ago
Connected to localhost.localdomain.
Mode: netascii Verbose: off Tracing: off Literal: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
> Try starting the socket not the service since the service is socket activated > systemctl start tftpd.socket =)
Hmm, I didn't know this..:)
Anyway, it seems to be working now. I'll give it some more testing.