search for: rlim_fd_max

...nd asked him what he was doing... synching his folders. It hung for a while but finally finished. I searched the archives and found some related info from Jeff Ballard: >Actually on Solaris 9 you want to put something like this in >/etc/system: > >set rlim_fd_cur = 32768 >set rlim_fd_max = 65536 > >That sets the current fd's to 32k and max to 64k. Unfortunately, to >take effect you'll need to reboot. After the reboot, ulimit -a should >show that nofiles(descriptors) is 32768. > >-Jeff And I found this from Jeff Earickson: >I ran into this p...

...ocks) unlimited unlimited data(kbytes) unlimited unlimited stack(kbytes) 8192 unlimited coredump(blocks) unlimited unlimited nofiles(descriptors) 10010 10010 vmemory(kbytes) unlimited unlimited /etc/system rlim_fd_max = 4096 rlim_fd_cur = 2048 Log entries possibly related to this problem(?): When we are in the period when the errors occurs and a user logs in we get this in the log: Æ2002/05/08 11:30:03, 0Å lib/debug.c:reopen_logs(349) Unable to open new log file /usr/local/samba/var/log.smbd: Too many open...

...TO: - Compilation issues regarding Citrix/metaframe - - ie the need to increase the MAX_CONNECTION setting before compilation - - ie how to compile samba to a 64 bit application to get more available file descriptors (problem for solaris) - the need to tweak the /etc/system settings (ie "set rlim_fd_max = <number>") - oplocks settings in smb.conf - the single smbd process issue and workaround(s) (wins and DNS-proxy/netbios names?) - the home-share issue and problem All these issues, and probably more, I feel are related to Citrix/metaframe vs. Samba. If I am wrong and somewhere there...

Hi, Does Samba 2.2.4 on Solaris 8 support 64 bit? We are using Clearcase & Rational told us that only samba 2.2.5 support 64 bit? Any help would be arreciated. Thanks, -Murali

...'t. I noticed that we see the error message: "Too many open files" each time drives are not mapped. In the log files I can see that it has happened even when we ran version 3.0.10. We run Samba on Solaris and have previously increased both "rlim_fd_cur" and "rlim_fd_max" to 1024. Do we need to increase these values further ? If I do "plimit <smbd process>" it says: resource current maximum time(seconds) unlimited unlimited file(blocks) unlimited unlimited data(kbytes) u...

...mvfs_dncregmax=4000 set mvfs:mvfs_dncdirmax=1600 set mvfs:mvfs_vobfreemax=4500 set mvfs:mvfs_cvpfreemax=4500 * GE-Link Parameter * Disable Autonegociation *set ge:ge_adv_1000autoneg_cap=0 *Begin Tuning for max number of open files *avoid samba error: Too many open files set rlim_fd_cur=1024 set rlim_fd_max=2048 *End Tuning for max number of open files - samba version 2.2.8a (64bit compiled) - smb.conf # Global parameters [global] workgroup = AD-Domain netbios name = SAMBA01 server string = Samba %v on (%L) security = DOMAIN encrypt passwords = Yes pas...

...'t. I noticed that we see the error message: "Too many open files" each time drives are not mapped. In the log files I can see that it has happened even when we ran version 3.0.10. We run Samba on Solaris and have previously increased both "rlim_fd_cur" and "rlim_fd_max" to 1024. Do we need to increase these values further ? If I do "plimit <smbd process>" it says: resource current maximum time(seconds) unlimited unlimited file(blocks) unlimited unlimited data(kbytes) u...

I could do with some help. We're creating a large number of files from from NT Workstation. After a while (I think it's 1014 files but it may be 2027), the SAMBA log reports "Out of file structure" errors. Below is a cut down version of the log file. The 1014 number is significant as it appears in the SAMBA log when SAMBA starts. I'm guessing it's a Solaris OS limit.

I am running Citrix Metaframe XP on Windows 2000 server and would like to have the ability to access files on my AIX Unix server. Are there any issues with Samba in a Windows Terminal Server environment? Thanks, Tim Brooks

Good Morning, I recently compiled Samba 2.2.7a as a 64bit executable on Solaris 8. The Solaris 8 server is configured to permit 65535 files to be open, while Samba has been configured to allow 65500 files to be open. These large number of files are required to permit simulataneous compilations to take place a single build server, though there are multiple build servers. Last time I tried to

Hi, i have 2 dovecot imap server running on solaris 10 The primary server with dovecot 1.0.alpha4 is running with best performance on Sun Sparc E4k5 with 8x 450MHz The secondary with rc10 has ugly performanceproblems on Sun E450 wth 4x 450MHz. Every new imap process takes permanent 25% cpu usage List the folder and fetch message are both slowy! Both servers are configred with ldap backend

I'm encountering problems copying files from a Windows NT workstation to a Linux system. Not all of the files are being copied. A week ago I submitted a bug report. The only response was an automated reply acknowledging that the message was received. I'm assuming that they are very busy and have not had time to go through all of the incoming e-mail. Maybe someone here could help, or

Anyone running Dovecot on Solaris, requiring only SSL connections, and servicing thousands of simultaneous users? Our past attempts to do so have failed due to dovecot-auth using up all 256 of its file descriptors. I say 256 since we are limited to that by the 32-bit libraries. We are looking at either compiling Dovecot in 64-bit and letting dovecot-auth file descriptors accumulate (not ideal),

...ovecot locking up with "Too many open files" syslog error messages. Last night, after several hours of "too many open files" complaints, the master dovecot process just died -- no core dump and no complaint to syslog. Per advice of the list, I have doubled the rlim_fd_cur and rlim_fd_max kernel parameters and rebooted my imap server. I also saw in my syslog: Sep 6 16:48:53 emerald dovecot: [ID 956436 mail.error] pipe() failed: Too many open files Sep 6 16:48:53 emerald dovecot: [ID 257797 mail.crit] dup2(stderr) failed: Bad file number With students back, they have been giving...