Will Linux shut down if /var fills up?
 

I am working with an application that actually wants the system to stop, but is currently coded to ignore errors attempts to write log entries. Are there normally critical system processes trying to log to /var that *will* cause a shut down if they are unable to log?

Thanks.

No, certainly not. Not unless there is some seriously bad coding going on somewhere. Can you be clearer about what you're really getting at here? Is that what you want?

AFAIK, Apache web server will throw a fit and croak if he can not write to his log files. Keep it in mind if you consider that to be a "critical system process" in your business.

I'm not sure about other daemons. I rather doubt the OS will come down, but I sure as hell would not want to find out.

I agree with acid_kewpie, it's not clear what you want to happen.

It's true that (usually) if a service is coded to ignore write-to-log errors, it's shouldn't try to shutdown the system.
However(!), the most common reason for write_to_log errors is lack of disk space and that will cause the system to slow down dramatically, possibly freeze.
Theoretically it could bring down the system.

What exactly is it you are after and/or what is happening on this system?

It does not. I have a testserver where I misconfigured logrotate (don't bring apache down first) so after a logrotate apache can not write to its logfile.

I can't locate where I read that at the moment, and don't particularly feel like arguing the point. Thanks for sharing your test scenario.

clarification of question
 

Thanks for the feedback folks. I am looking at a security application and I actually want the system (or at least the application) to stop if it can no longer generate log entries. (because a stopped system is a secure system, right? :)) Unfortunately the application is coded to ignore log write errors and the product vendor doesn't want to make any coding changes, no matter how small. I used Linux a lot in the past, but was never very familiar with the logging stuff and the handling of disk space runouts.

It's happened a number of times for me on my remote systems (usually from a mis-behaving windows box flooding samba with requests).

The OS doesn't shut down, and more often than not the server processes don't die either. What happens is the pending log-writes queue up into memory, and you see a slow degradation of performance when it eats up too much memory. I'm not sure about all daemons, but samba, cups, ssh, ftp, login and all the other standard services will keep running fine.

If you're worried, you can test it.

Both samba and cups are known for copious logging, so they offer an easy way to test this situation. On a system with not much space left in var (a few megs, or a few hundred), have samba serve cups printers. If you want the test to run faster, turn up the logging factors for samba and cups. Add a bunch of queues to cups (100-200, they don't even have to be real). Now when a windows client prints through the server, it will first check the status of each and every printer on the server (I don't know why, but it does. It's windows OK?). This generates a bunch of lines in samba for each printer, and a bunch in cups for each printer as well. Your var will fill up, and you can watch the behavior of your other services. In my experience, everything runs just fine until you run out of memory.

Re post #7; in that case, you need a disk monitor that alerts you when avail diskspace < X% eg 85%.
For a simple case you can roll your own, otherwise there is monit, nagios etc, etc.