https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c32 --- Comment #32 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 13:32:37 UTC ---
I think I found the error. (from comment 30) No, that's not the error. It is a temporary workaround.
Sorry, but it will be another day before I get the "lsof" output mentioned in comment 23. My first attempt at that failed, as reported in comment 26. Since then, I have rebooted (for entirely unrelated reasons). I do have the "lsof" output from the initial run of dhclient (acquiring the lease), but I don't yet have it for a lease renewal. For aquiring a lease, fd 2 is open to "/dev/null", which ought to be fine. But then I was never having dhclient problems on the initial lease. They only showed up for me on renewals. When I do get the "lsof" output, here is what I am expecting to see: Either: fd 2 is open for read only to the script file, or: fd 2 is not open at all (was inadvertantly closed). If my guess is right, then this is all related to what I have been calling a kernel bug in comments 26-28. The reason for this expectation: It is inconceivable to me that the "dhclient" binary would open "dhclient-script" for append - that's not the kind of mistake that programmers would make. It cannot be opening it for write, as that would truncate the file even if nothing is written to stderr. So it looks to me as if there is something funky about the implementation of "/dev/fd/n" which allows echo string > /dev/stderr to write to the file even when the stderr file descriptor is not open for output. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.