## 15.5. Limiting File Sizes

Here are techniques to keep you from creating large files (which can happen by accident, such as with runaway programs). Your shell may be able to set process limits. If you're writing a program in C or another language that has access to kernel system calls, you can set these limits yourself. And there's one more trick you can use.

These limits are passed to child processes. So, if your shell sets a limit, all programs you start from that shell will inherit the limit from their parent process.

### 15.5.1. limit and ulimit

Many shells have a built-in command that uses system calls to set resource limits. This is usually done from a shell setup file (Section 3.3), but can also be done from the command line at a shell prompt. To set a maximum file size in C-type shells and zsh , use the command `limit filesize` `max-size`. In the Korn shell and bash, use `ulimit -f` `max-size`. For example, the following csh and ksh commands keep you from creating any files larger than 2 MB:

>     % limit filesize 2m
>     $ ulimit -f 2000

Similarly, on many systems, you can use limit and ulimit to restrict the size of core dump files. Core dumps are generally large files, and if you are not actively developing or debugging, they are often not interesting or useful. To set a maximum size for core dumps, execute one of these commands:

>     % limit coredumpsize max-size
>     $ ulimit -c max-size

To eliminate core dumps entirely, use `0` (zero) for `max-size`. Because core dumps are essential for effective debugging, any users who actively debug programs should know the commands `unlimit coredumpsize` (which removes this restriction in csh ) and `ulimit -c unlimited` for bash and ksh.

### 15.5.2. Other Ideas

File size limits only apply to processes that are invoked from a shell where the limit is set. For instance, at and cron jobs might not read the shell setup file (Section 3.3) that sets your limit. One way to fix this is to set the limit explicitly before you start the job. For instance, to keep your cron job named cruncher from core-dumping, make the crontab entry similar to one of these:

`;` Section 28.16

>     47 2 * * *   ulimit -c 0; cruncher
>     47 2 * * *   bash -c 'ulimit -c 0; exec cruncher'

If you've written a daemon (Section 1.10) in C that starts as your workstation boots up (so no shell is involved), have your program invoke a system call like ulimit(3) or setrlimit(2).

If the unwanted files are created in a directory where you can deny write permission to the directory itself -- and the files are not created by a process running as root (filesystem permissions don't apply to root) -- simply make the directory unwritable. (If the process needs to write temporary files, have it use /tmp. An environment variable such as TMP or TMPDIR may control this.)

You can prevent the files from being created by putting a zero-size unwritable file in the directory where the files are being created. Because the file is zero-length, it doesn't take any disk space to store:

`chmod` Section 50.5

>     % touch core
>     % chmod 000 core

If all else fails, try making a symbolic link to /dev/null (Section 43.12).

--ML and JP

Copyright © 2003 O'Reilly & Associates. All rights reserved.