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: /etc/init.d/pure-ftpd /etc/xinetd.d/pure-ftpd Version-Release number of selected component (if applicable): chkconfig-1.3.37-2.x86_64 How reproducible: 100% Steps to Reproduce: 1. yum install pure-ftpd 2. chkconfig --list pure-ftpd or 2. chkconfig pure-ftpd on Actual results: chkconfig operates only on the SysV pure-ftpd service. There's no way to query or configure the xinetd pure-ftpd service using chkconfig. Expected results: chkconfig should take an optional parameter to disambiguate between SysV and xinetd services. e.g.: chkconfig --list --type xinetd pure-ftpd or chkconfig --type xinetd pure-ftpd on Another use-case: chkconfig --list --type sysv (to skip listing xinetd services) Additional info: 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: http://git.fedorahosted.org/git/?p=chkconfig.git;a=commitdiff;h=aab0a3bdb6b8d22727aa7a3baf1339fac7d5bb28 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?
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days