Hot answers tagged file-descriptors
ulimit only changes the resource limits for the current shell and its children; sudo ulimit creates a root shell, adjusts its limits, and then exits (thus having, as far as I can see, no real effect). To exceed 12288, you need to adjust the kernel's kern.maxfiles and kern.maxfilesperproc parameters, and also (at least according to this blog entry, which is ...
The following should resolve most solutions (and are listed in order of their hierarchy): echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf echo 'ulimit -n 4096' | sudo tee -a /etc/profile Notes: You will need to restart for these changes to take effect. ...
-f follows by inode. If you want to follow by name, such as when a program completely recreates the file, then use -F instead.
It seems that OS X Lion will not permit "unlimited" as a value: % sudo launchctl limit maxfiles 8192 unlimited Neither the hard nor soft limit for "maxfiles" can be unlimited. Please use a numeric parameter for both. Providing numerical values for both the soft and the hard limit does the job: % sudo launchctl limit maxfiles 4096 8192
On Mavericks its simple. As a regular user: ulimit -n 8192 You can check the updated settings via ulimit -a On my machine: ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 -c: core file size (blocks) 0 -v: ...
Beyond the standard file descriptors there are 3-1024. These can be created in scripts with the exec 10<> afilename From this point on, anything written to file descriptor 10 gets written to afilename When you have ./script.sh 10>&1 You are redirecting anything that would have gone to file descriptor 10 to stdout. You'll want to ...
The lsof command will tell you all the open files and what program has them open. lsof filename
Each process has it's own FD - table (see http://en.wikipedia.org/wiki/File_descriptor ), otherwise process A would have to communicate with process B about the filedescriptors (and not only with B but also with all the other processes on the machine). So, just knowing the (internal) FD is not enough, you need to know where this FD points to: $> ls ...
Somehow the process still writes to a file even though I've renamed it. This is called normal operation of the operating system. Once the file is opened, it doesn't matter one whit to the process(es) with the open file descriptor what name(s) the file has, or even whether the file has a name at all. Simply put, your program's logging scheme (if that ...
Open your terminal and type as sysctl fs.inotify.max_user_watches to check current limit. If you want to modify it then type in terminal as root vim /etc/sysctl.conf Then at the end add this following line fs.inotify.max_user_watches = XXXXXX In the XXXXXX place your desired value. let me know if you are still facing any issues.
No, it does not show the limit - just the usage. >>> import resource >>> resource.setrlimit(resource.RLIMIT_NOFILE, (10000, 10000)) >>> resource.getrlimit(resource.RLIMIT_NOFILE) (10000, 10000) Now: >>> for i in range(5000): ... f=open('/tmp/delme'+str(i),'w') ... fs.append(f) And: laptop:/proc/20160$ cat ...
Afaik, on Linux the per-process limit of open files is controlled via the ulimit command. From man ulimit: NAME ulimit - set or report file size limit DESCRIPTION The ulimit utility shall set or report the file-size writing limit imposed on files written by the shell and its child processes (files of any size may be read). Only a process with ...
Patch files are human readable and can be opened and viewed on most text editors(Notepad++ being my preferred)
If you mean .patch files as produced by standard Unix/Linux diff(1) tool and applied by patch(1) tool, then there's a convention on having description for them right inside the patch file, at the beginning of it (that's because patch(1) tool will ignore anything before the actual patch header in the file). Here's typical example from a Linux kernel patches. ...
Unlocker is a great tool for this. It lists all applications that are locking a file (or directory). It closes the handle without terminating the application that is locking the file. Make sure you download the 64-bit version if yiu have a 64-bit OS.
I use SysInternals' Process Explorer. Search for the locked file. Not only will PE tell you which application locked it, but also what thread in that application opened it. In certain cases (only recommended if you know what you're doing!) you can get away by killing one thread, rather than an entire application. At any rate, it will tell you who locked the ...
Only top voted, non community-wiki answers of a minimum length are eligible