No, it is no longer relevant. Item 1 is addressed in the new man page, items 3 and 4 are no longer true under SMF/Greenline and item 2 was never true IMHO.
[EMAIL PROTECTED] wrote: > 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] -- blu Screening ideas are indeed thought up by the Office for Annoying Air Travelers and vetted through the Directorate for Confusion and Complexity - Kip Hawley, Head of the TSA ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ networking-discuss mailing list [email protected]
