Bug 983893

Summary: you have to restart xinetd when you enable tftpd service
Product: [Fedora] Fedora Reporter: Jan Hutař <jhutar>
Component: xinetdAssignee: Jan Synacek <jsynacek>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 18CC: jsynacek, kvolny, qe-baseos-daemons
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-04 07:04:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Hutař 2013-07-12 07:51:25 UTC 
Description of problem:
When you enable tftpd service, you have to restart xinetd. This was not required on RHEL6.


Version-Release number of selected component (if applicable):
xinetd-2.3.15-4.fc18.x86_64
tftp-5.2-6.fc18.x86_64
tftp-server-5.2-6.fc18.x86_64


How reproducible:
always


Steps to Reproduce:
1. Make sure tftpd is dsabled and restart xinetd to have clean state
   # grep disable /etc/xinetd.d/tftp
	disable			= yes
   # service xinetd stop
2. # tftp -l -m binary 127.0.0.1 -c get <...>/vmlinuz
   Transfer timed out.
   This is good and expected.
3. # sed -i 's/^\(\s\+disable\s\+=\) yes$/\1 no/' /etc/xinetd.d/tftp
4. # tftp -l -m binary 127.0.0.1 -c get <...>/vmlinuz
   Transfer timed out.
5. # service xinetd restart
6. # tftp -l -m binary 127.0.0.1 -c get <...>/vmlinuz
   # echo $?
   0
   # ls vmlinuz
   vmlinuz


Actual results:
You have to restart xinetd so it notices tftpd was enabled


Expected results:
You do not have to restart xinetd to make it notice tftpd was enabled


Additional info:
When I attempt to enable tftp using `systemctl enable tftp` it do not help as well:

# systemctl enable tftp
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
# echo $?
0
Comment 1 Jan Synacek 2013-10-04 07:04:42 UTC 
You always have to restart xinetd so it notices any changes. Or you can send SIGHUP to do the same. I don't know how it works on RHEL6.

On Fedora, use systemctl.

(In reply to Jan Hutař from comment #0)
> Additional info:
> When I attempt to enable tftp using `systemctl enable tftp` it do not help
> as well:
> 
> # systemctl enable tftp
> The unit files have no [Install] section. They are not meant to be enabled
> using systemctl.
> Possible reasons for having this kind of units are:
> 1) A unit may be statically enabled by being symlinked from another unit's
>    .wants/ or .requires/ directory.
> 2) A unit's purpose may be to act as a helper for some other unit which has
>    a requirement dependency on it.
> 3) A unit may be started when needed via activation (socket, path, timer,
>    D-Bus, udev, scripted systemctl call, ...).
> # echo $?
> 0

See 3). Tftp is activated via a socket.

# systemctl enable tftp.socket

# systemctl start tftp.socket

# systemctl status tftp.socket
tftp.socket - Tftp Server Activation Socket
         Loaded: loaded (/usr/lib/systemd/system/tftp.socket; enabled)
         Active: active (listening) since Fri 2013-10-04 08:57:50 CEST; 3s ago
         Listen: [::]:69 (Datagram)