tags 608624 + upstream
quit
Christian PERRIER wrote:
> Maybe...but that should rather be discussed directly with upstream,
> imho. Not sure I'll have the motivation to play proxy, here..:)
I wrote the following to sa...@lists.samba.org as a reply to
<20100125175026.gc23...@samba1>. Copying here because I am not sure
if it was delivered correctly to that members-only list. I haven't
tried filing an upstream bug yet because as you noted it is not cut
and dried what the best fix is.
Jeremy Allison wrote:
> On Mon, Jan 25, 2010 at 11:44:03AM +0000, Miguel Medalha wrote:
>> rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)
>>
>> I searched Google for some answer but I couldn't find a satisfactory
>> one. What should I do to solve this?
[...]
> It's a warning, you can safely ignore it. Windows 7 clients need to
> have exactly the same number of open handles available as Windows
> servers, else it fails in some file copy situations with a "out of
> handles" message. Samba has taken care of it for you, but it's just
> letting you know your fd limit is set a bit low.
Uninformed reaction: is it useful to let the user know? Does setting
the fd limit higher result in better behavior, or does the automatic
increase have results that would be counterintuitive if not mentioned?
If the former, maybe the default rlimit_max should be increased
(on Debian squeeze it seems to be 1024 fwiw). If the latter, I think
the message should say
rlimit_max: rlimit_max (8192) increased to minimum Windows limit (16384)
to be more informative and sound less like a warning. Like this,
maybe (untested).
-- 8< --
Subject: s3-param: Make "rlimit_max below minimum Windows limit" notification
less scary
The fix to bug #6837 results in messages from testparm that look
like a misconfiguration even though they aren't:
rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)
Apply a slight change in wording ("increasing rlimit_max to minimum
Windows limit") to make it clearer that the user has done nothing
wrong. (Similarly for sysctl_max.)
Reported-by: Miguel Medalha <miguelmeda...@sapo.pt>
Signed-off-by: Jonathan Nieder <jrnie...@gmail.com>
---
source3/param/loadparm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/source3/param/loadparm.c b/source3/param/loadparm.c
index 2f68f00..bda20d8 100644
--- a/source3/param/loadparm.c
+++ b/source3/param/loadparm.c
@@ -4898,7 +4898,7 @@ static int max_open_files(void)
#endif
if (sysctl_max < MIN_OPEN_FILES_WINDOWS) {
- DEBUG(2,("max_open_files: sysctl_max (%d) below "
+ DEBUG(2,("max_open_files: increasing sysctl_max (%d) to "
"minimum Windows limit (%d)\n",
sysctl_max,
MIN_OPEN_FILES_WINDOWS));
@@ -4906,7 +4906,7 @@ static int max_open_files(void)
}
if (rlimit_max < MIN_OPEN_FILES_WINDOWS) {
- DEBUG(2,("rlimit_max: rlimit_max (%d) below "
+ DEBUG(2,("rlimit_max: increasing rlimit_max (%d) to "
"minimum Windows limit (%d)\n",
rlimit_max,
MIN_OPEN_FILES_WINDOWS));
--
1.7.4.rc0
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
