Bug 1167777
| Summary: | 'chkconfig tftp on' fails to enable tftp | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Karel Volný <kvolny> | ||||
| Component: | tftp | Assignee: | Jan Synacek <jsynacek> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.1 | CC: | jikortus, lnykryn, pholica | ||||
| Target Milestone: | rc | Keywords: | EasyFix, Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Cause: Missing logic in tftp unit file.
Consequence: Executing "chkconfig tftp on" doesn't correctly enable the tftp service to be automatically started on boot.
Fix: Additional logic was added to the unit file.
Result: Running "chkconfig tftp on" now correctly enables the service.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-11-19 04:40:07 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1110700, 1191021 | ||||||
| Attachments: |
|
||||||
ahem, steps 1. and 4. were written with the old way in mind, using systemd, it'd be some kind of 'systemctl ... tftp.socket' magic as noted at the end of the description, sorry for possible confusion Uh, why is tftp-servcer shipping both unit files and also configuration for xinetd? But you can still enable tftp with xinetd through chkconfig, just use chkconfig --type xinetd tftp on (like in the case that there was an initscript and xinetd service with the same name). I have written a support for systemd socket activation to chkconfig but it only works for .socket and @.service pairs. In cases like this I don't have the information if .service or .socket should be enabled. What I would suggest is to put this to tftp.service [Install] Also=tftp.socket This would mean that enable on tftp.service is still noop, but it will also enable the socket. I think we should go with this solution, because it will a) fix the problem with chkconfig b) it will also make possible to just type systemctl enable tftp instead of tftp.socket which I think is more user-friendly In Fedora, this was fixed by http://pkgs.fedoraproject.org/cgit/tftp.git/commit/?id=1f86b3299f04684be5db03409fd4e6d392bca804. I'll go with the same fix here, since using Also= doesn't quite work in this case. Created attachment 961633 [details]
patch
(In reply to Lukáš Nykrýn from comment #3) > But you can still enable tftp with xinetd through chkconfig, just use > chkconfig --type xinetd tftp on (like in the case that there was an > initscript and xinetd service with the same name). um, that still doesn't work ... [0 root@pipa02 ~]# chkconfig --type xinetd tftp on [0 root@pipa02 ~]# tftp 127.0.0.1 -c get somenonsense Transfer timed out. (but it at least modifies /etc/xinetd.d/tftp ) and is a change from RHEL6 where '--type xinetd' wasn't needed > b) it will also make possible to just type systemctl enable tftp instead of > tftp.socket > which I think is more user-friendly 100% agreed, it'd be much easier to use this way (In reply to Karel Volný from comment #6) > > chkconfig --type xinetd tftp ... > and is a change from RHEL6 where '--type xinetd' wasn't needed well, I mean ... after applying the patch from comment #5, '--type xinetd' won't be needed too, but it will do the things the systemd way which is inconsistent in RHEL6 you could do chkconfig tftp enable chkconfig --type xinetd tftp disable et vice versa and you'd get the desired effect in RHEL7 if you'd do chkconfig tftp enable chkconfig --type xinetd tftp disable then to my best understanding tftp(.service) will keep running I'd tend to disregard this as obvious admin error, using the commands inconsistently, but I don't know how much do we want to keep the old behaviour (as chkconfig is a compatibility layer - those who want the new behaviour use systemctl directly I guess ...) Well the problem here is that we are shipping both xinetd configuration file and systemd unit-file. If you would ship initscript and xinetd file in rhel6 you would be in the same situation. I would not complicate it. After the fix chkconfig tftp (en|dis)able will work and if you are using --type you should know what you are doing. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2192.html |
Description of problem: In RHEL6, you could enable/disable tftp using chkconfig. This no longer works in RHEL7. Version-Release number of selected component (if applicable): chkconfig-1.3.61-4.el7 How reproducible: always Steps to Reproduce: 1. make sure tftp is off ('disable = yes' in /etc/xinetd.d/tftp, restart xinetd) 2. chkconfig tftp on 3. tftp 127.0.0.1 -c get somenonsense 4. make sure tftp is on ('disable = no' in /etc/xinetd.d/tftp, restart xinetd) 5. chkconfig tftp off 6. tftp 127.0.0.1 -c get somenonsense Actual results: 3. Transfer timed out. 6. Error code 1: File not found Expected results: 3. Error code 1: File not found 6. Transfer timed out. Additional info: I refer to bug #1021723 comment #10 which suggests, as I read it, to enhance chkconfig to be able to enable/disable tftp with systemd as backend. Note, from bug #983893 I'd understand that in the past it fliped "disable =" state in /etc/xinetd.d/tftp and sent SIGHUP to xinetd process, while now it needs to do 'systemctl enable tfpt.socket; systemctl start tftp.socket' (or stop/disable respectively) instead of trying to refer to 'tftp.service'.