Red Hat Bugzilla – Bug 467863
chkconfig can't distinguish between SysV and xinetd services of the same name
Last modified: 2014-03-16 23:16:09 EDT
Created attachment 321007 [details]
add an optional --type <sysv|xinetd> parameter to chkconfig
Description of problem:
There's no way chkconfig could enable/disable a xinetd service if there exists a SysV service of the same name. A real example is pure-ftpd which installs both:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install pure-ftpd
2. chkconfig --list pure-ftpd
2. chkconfig pure-ftpd on
chkconfig operates only on the SysV pure-ftpd service. There's no way to query or configure the xinetd pure-ftpd service using chkconfig.
chkconfig should take an optional parameter to disambiguate between SysV and xinetd services.
chkconfig --list --type xinetd pure-ftpd
chkconfig --type xinetd pure-ftpd on
chkconfig --list --type sysv (to skip listing xinetd services)
I'm attaching a patch to add this functionality to chkconfig.
As this changes the command line options and adds new translatable strings, this will have to wait until post-F10. Looks reasonable at a first glance, though.
Took a bit of massaging, but added in:
Will be in 1.3.40-1.
Would it be possible to have this in F-9, F-10?
As system-config-services uses chkconfig to find out about how services are configured, it gets confused with old chkconfig versions that return the SysV status when it attempts to query the xinetd "incarnation" of the pure-ftpd service. Mind that I intend to make system-config-services cope better with chkconfig yielding unexpected results, but it'd be good if a user would be able to configure both types of the pure-ftpd service from the GUI.
FYI, bug #467871 is the corresponding system-config-services bug.
Given that 1.3.40 has the fix for bug 474223 in it, I'm a bit leery of dropping that on an existing release. Theoretically, none of the included Fedora software should be invoking it as install_initd, though.
(In reply to comment #5)
> Given that 1.3.40 has the fix for bug 474223 in it, I'm a bit leery of dropping
> that on an existing release.
Judging from the reporter's latest comment in that bug, there still seems to be a problem with the patch. According to comments he made in the linuxbase.org bugzilla ticket, he would have reopened bug #474223 if he knew how. I've told him in the "upstream" ticket that he should be able to just change the status back from CLOSED, I hope I don't step on your toes with that ;-).
Anyway, I planned to just let s-c-services check the version of chkconfig (by parsing `chkconfig --version`) and either use "--type ..." if it's >= 1.3.40 or do more sensible things with older versions than throwing around exceptions if it can't parse chkconfig output (e.g. if it gets SysV-formatted output when checking an xinetd service).
Perhaps we can let these fixes mature just a bit in Rawhide and push them back to F-9, F-10 when the beta is out for a while, i.e. they got a certain amount of testing?