Description of Problem: The inetdconvert script does not respect that, and will create faulty "additional" parameters equal to the server name. How Reproducible: Every time Steps to Reproduce: 1. Add this line to the file /etc/inetd.conf 2. Make sure that xinetd does not know about telnetd (temporarily remove the file from /etc/xinetd.d) 3. Try to convert /etc/inetd.conf file with : inetdconvert --convertremaining 4. Restart xinetd 5. Try to telnet to the machine. 6. Get an error message like this : Usage: telnetd [-debug] [-D (options|report|exercise|netdata|ptydata)] [-h] [-L login_program] [-n] [port] Because in.telnetd appears into the telnetd server parameters.
You didn't enter the line you mentioned...
Oops, sorry about that. I had to switch between the Javascript/Non-Javascript version of bug submission (StarOffice has some more homework to do...) Here is the kind of faulty line that will trigger the error : telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd Notice that the argv[0] parameters in.telnetd is going to be included into the xinetd args parameters, causing the problem.
But doesn't that line say just the same? Run /usr/sbin/in.telnetd with argument "in.telnetd" - this looks like a bad modification of the standard "/usr/sbin/tcpd in.telnetd"?
Sorry again, I was in a hurry and a lot has been lost into the migration from the Javascript to the non-Javascript version of the submission form. The line I submitted is the official-ad-requested-by-the-inetd-man-page way to set up a server _without_ using the tcpwrapper. This is the pathological case that triggers this problem : when you have some servers that should be launched by inetd _whithout_parameters_, then you have to provide argv[0] nonetheless. This is peculiar, but this is it !!! I have to went through an exegesis of the inetd.conf/xinetd.conf man pages to understand. Here are the exerpt that showed me the light : From inetd.conf man page : (...beginning...of...inetd.conf...) Upon execution, inetd reads its configuration information from a configu- ration file which, by default, is /etc/inetd.conf. There must be an entry for each field of the configuration file, with entries for each field separated by a tab or a space. Comments are denoted by a ``#'' at the beginning of a line. There must be an entry for each field. The fields of the configuration file are as follows: service name socket type protocol wait/nowait[.max] user[.group] server program server program arguments (...) The server program arguments should be just as arguments normally are, starting with argv[0], which is the name of the program. If the service is provided internally, the word ``internal'' should take the place of this entry. (...end...of...inetd.conf...) Note how they _insist_ on the fact that there must be an entry for _each_ fields, including the server program arguments. Now, if we look at the xinetd.conf man page : (...) server_args determines the arguments passed to the server. In contrast to inetd, the server name should not be included in server_args. (...) So, as you can see, the designers of xinetd really looked at that problem before. The problem is that the inetd -> xinetd configuration utility _does_ not make that distinction. It's no bgi deal to correct, the only problem is that I do not know python enough to send a patch.
Fixed in xinetd-2.3.0-3