This CR has been around for about a decade before it finally landed in my lap. Can someone tell me if it is still relevant and if so, how to resolve it?
Thanks Doug -------- Original Message -------- Subject: CR 4126516 douglas.stevenson, Now responsible engineer P4 manpage/section3sock Bad inetd, inetd.conf, listen (3n) man pages Date: Tue, 28 Aug 2007 15:33:31 -0600 (MDT) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] *Synopsis*: Bad inetd, inetd.conf, listen (3n) man pages http://bt2ws.central.sun.com/CrPrint?id=4126516 Due to a change requested by [EMAIL PROTECTED], [EMAIL PROTECTED] is now the responsible engineer for: CR 4126516 changed on Aug 28 2007 by [EMAIL PROTECTED] === Field ============ === New Value ============= === Old Value ============= Responsible Engineer [EMAIL PROTECTED] [EMAIL PROTECTED] ====================== =========================== =========================== *Change Request ID*: 4126516 *Synopsis*: Bad inetd, inetd.conf, listen (3n) man pages Product: solaris Category: manpage Subcategory: section3socket Type: Defect Subtype: Status: 3-Accepted Substatus: Priority: 4-Low Introduced In Release: Introduced In Build: Responsible Manager: [EMAIL PROTECTED] Responsible Engineer: [EMAIL PROTECTED] Initial Evaluator: Keywords: 2.5, 2.5.1, 2.6, 2.7 === *Description* ============================================================ [EMAIL PROTECTED] 1998-04-07 (Consult [EMAIL PROTECTED] of kernel group about questions arising from this description) In the process of fixing bugs in the font server, it has become clear that the man (manual) pages for inetd, inetd.conf, and listen (3n) are terribly misleading or just simply wrong depending on how you look at it. This is a CRITICAL problem as more and more people attempt to write various kinds of servers based upon Sun hardware and software. Thus it is EXTREMELY important that this information be correct and complete. More specifically, I found the following defects: 1. WAIT VERSUS NOWAIT AND ACCEPT. Although the man page for inetd.conf discusses the wait/nowait parameters, no where does it mention the word "accept" in relation to these parameters. The man page actually states: "nowait for all but "single-threaded" datagram servers - servers which do not release the socket until a timeout occurs. These must have the status wait." Since the sample server I was writing was NOT a datagram server, this statement says that I should use the "nowait" parameter which according to information received from [EMAIL PROTECTED] of the kernel group is incorrect. Thus this statement is in error since it implies something that is not true. I think this should be remedied by altering the documentation to state that if your tcp server is performing an "accept" that the parameter should be set to "wait". 2. LISTEN MAN PAGE. If one does a: man -s3n listen to look at the listen man page, no where does it state that that you should receive a EINVAL error (i.e, the error "22" that I was getting from the listen). Further, it should state that this error "22" (EINVAL) can occur as the result of "nowait" being erroneously being specified in the inetd.conf file instead of "wait". I think having this information in this man page would prevent alot of errors and needless questions. 3. INETD RESTART. Again, according to information form [EMAIL PROTECTED] of the kernel group, changing nowait to wait and doing a "kill -HUP" on inetd is NOT sufficient to get inetd to do the right thing. I think this should be fixed in either the code or the documentation. If you must follow the steps stated by [EMAIL PROTECTED] (i.e., edit the file, do a kill -HUP, edited the file again, do another kill -HUP) then the documentation should state this. Actually, I think this should be fixed in the code. I think inetd's parsing of this file should be robust enough to detect a change of "nowait" to "wait" and do the correct thing. It does not speak well of inetd that it cannot detect this kind of change upon the user doing a "kill -HUP" on it. If it's too much trouble to fix in the code then I strongly suggest that it be corrected in the documentation. 4. RECOURSE TO REBOOTING. After inetd disappears for whatever reason (I know of no good reason why it should have but it did), is there any recourse other than rebooting? If so, whatever it is should go into the documentation. Rebooting is a real pain so if there is any reliable alternative to rebooting it should be stated. Also, if there is a recourse to rebooting then this method (whatever it is) sounds like a good way to get inetd to parse the inetd.conf file from scratch and thus get around the inetd parsing problem of the wait/nowait parameters. If there is no guaranteed reliable way of getting inetd to parse inetd.conf correctly other than rebooting then the documentation should state this. *** (#1 of 1): 2004-08-03 05:27:19 GMT+00:00 [EMAIL PROTECTED] *** Last Edit: 2004-08-03 05:27:19 GMT+00:00 [EMAIL PROTECTED] === *Comments* =============================================================== [EMAIL PROTECTED] 1998-04-07 - Re-categorize to man page group [EMAIL PROTECTED] 1998-04-26 ---------------------------- What release of OS are the observations in the description section based on ? Atleast some of the error behavior for listen(3n) did change in Solaris 2.6 and I wonder if all observations apply. Some comments - the single threaded vs multi threaded terminology used in inetd predates invention of threads and has nothing to do with threads. That can use improvements. - The "wait" vs "nowait" server is complicated and not explained well anywhere. Explaining it without example code would be a challenge. Books like "Unix Network Programing" (Richard Stevens) have tried but do not address all issues. Example code for a TCP "wait" server has benefits but not found even in public domain easily. The only public domain code using that feature I have seen is some modified httpd servers. Books usually say use "nowait" for TCP and "wait" for UDP. - Any issues with inetd restart should be evaluated as bugs first before any behavior gets documented. *** (#1 of 1): 2004-08-03 05:34:04 GMT+00:00 [EMAIL PROTECTED] *** Last Edit: 2004-08-03 05:34:04 GMT+00:00 [EMAIL PROTECTED] === *Evaluation* ============================================================= Will work with [EMAIL PROTECTED] to make changes for 2.7 fcs. [EMAIL PROTECTED] 1998-06-11 Will work with [EMAIL PROTECTED] to make changes for next release. [EMAIL PROTECTED] 1998-07-28 [EMAIL PROTECTED] 2003-12-04 changed RE to mark.ruddell [EMAIL PROTECTED] 2004-01-16 Changing RE to me. [EMAIL PROTECTED] 2004-07-31 Unfortunately, this bug was never addressed completely, as far as I can see. Now, because of Greenline, the issues with inetd(1M) and inetd.conf(4) become moot in S10. I'm unsure whether the complaint vs. listen(3N) (now listen(3SOCKET)) remains relevant. Am changing subcat to 3socket. [EMAIL PROTECTED] 2004-08-02 Accepted. Will investigate. *** (#1 of 1): 2004-08-03 05:29:51 GMT+00:00 [EMAIL PROTECTED] *** Last Edit: 2004-08-03 05:29:51 GMT+00:00 [EMAIL PROTECTED] === *Suggested Fix* ========================================================== === *Workaround* ============================================================= === *Justification* ========================================================== Documentation is CRITICAL to the correct development of servers on Sun workstations. Since this is something that is being done with ever greater frequency, it is imperative that this information be complete and correct. Hence, the high priority attached to this bug Justification by: sweber Date: 1998-06-11 Priority from 2 to 3: nroff source is frozen during sgml conversion. Will work with engineers to make changes for 2.7 fcs. Justification by: sweber Date: 1998-07-28 Priority from 3 to 4: Engineering resources are unavailable to assist in fixing this documentation bug for this release. *** (#1 of 1): 2004-08-03 05:31:51 GMT+00:00 [EMAIL PROTECTED] *** Last Edit: 2004-08-03 05:31:51 GMT+00:00 [EMAIL PROTECTED] === *Additional Details* ===================================================== Targeted Release: Commit To Fix In Build: Fixed In Build: Integrated In Build: Verified In Build: See Also: Duplicate of: Hooks: Hook1: Hook2: Hook3: Hook4: Hook5: Hook6: Interest List: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Program Management: Root Cause: Requires Security Coordination: false Fix Affects Documentation: No Fix Affects Localization: No Reported by: === *History* ================================================================ Date Submitted: 1998-04-07 17:14:00 GMT+00:00 Submitted By: [EMAIL PROTECTED] Status Changed Date Updated Updated By 1-Dispatched 1998-04-07 17:14:00 GMT+00:00 [EMAIL PROTECTED] 3-Accepted 1998-04-07 18:08:00 GMT+00:00 [EMAIL PROTECTED] === *Solution* =============================================================== === *Service Request* ======================================================== ID: 330240 Customer: Account Name: SunSoft, Inc. Contact Role: D-Development Impact: Significant Functionality: Primary Severity: 2 Synopsis: BugTraq+ Customer Call Record for Bugid # 4126516 Product Name: solaris Product Release: solaris_7 Product Build: 2.7 Operating System: 2.7 Hardware: generic Reference Number: Sun Contact: [EMAIL PROTECTED] Customer Contact: Rob Johnson Contact Type: I-Internal (SMI) Customer Status: Source: BugTraq+ Reproducible: Submitted By: [EMAIL PROTECTED] Submitted Date: 1998-04-07 17:14:00 GMT+00:00 Description: BugTraq+ Sun Contact: robjoh === *Activity* =============================================================== === *Multiple Release (MR) Cluster* - 0 ====================================== === *Escalations* ============================================================ _______________________________________________ networking-discuss mailing list [email protected]
