Will Linux work correctly when root partition is completely filled up?

Let's say my application is running on different partition and has enough space. What about Linux kernel? Will it continue running even when for example it will have no space to write logs?

Edit: Adding some more information. Everything is on root partition, also /tmp, /var, even /usr/bin, /usr/sbin.

On separate partition is only long running Java application which is also writing the logs to the same (empty) partition.

Are there any problems which could occur and influence the application?

  • 2
    This is unanswerable without more information. E.g. my old Pentium-1 100Mhz Linux installs had many (11) partitions and log files were on their own filesystem. So yes, writing logs when / was full was not a problem. What you might want to ask is what happens when / is full and something needs to be written there (e.g. changes to /etc/mtab) and no weird things like /etc on a own filesystem. (Assume / only has what is need for the OS to boot. E.g. /, /sbin, /bin, /etc ... but no /usr/bin, no /usr/sbin/ etc etc).
    – Hennes
    Oct 13 '14 at 19:43
  • 1
    Also, is this just theoretical or are you trying to solve a practical problem. And is full 100% full (the default at which a user can not write to it) or 105% full (assuming the default 5% reserved for root on ext2).
    – Hennes
    Oct 13 '14 at 19:45
  • 1
    I agree with @Hennes, is /tmp or /var on root? if so, you're in a lot of trouble. If not, you'll probably be fine. Oct 13 '14 at 20:18
  • @RichHomolka why I'm in trouble if /tmp and /var is on root partition?
    – Lubo Sach
    Oct 13 '14 at 22:29
  • @LuboSach there are user processes the write to /tmp and /var in normal processing. if /tmp is full, a lot of those normal processes don't run correctly, and your system suffers. You can't see this because mail is in /var and your warning "hey the system is hosed" emails don't happen :) Oct 13 '14 at 22:49

The kernel will be fine.

The kernel doesn't really write logs directly, but hands off logs to a userspace process. I think it's either through device driver or a socket. This is why syslog is needed and why a sorting mechanism for what comes from the kernel is also needed - the kernel just spits out logs and expects a userspace application to do whatever after that.

The worst that can happen there is the userspace process doesn't write what the kernel gave it. This is also why in a system you want to watch closely you want it to write heartbeat lines to your log every so often (like "---MARK---" or something like that). I believe the kernel reserves a bit of memory for itself permanently to hold the current log message it's trying to convey, it doesn't write directly to disk.

  • What will your application do when it can't write to the log directory? I don't know, it depends on the application. There's a non-zero chance that your application will crash, it depends on what the developers programmed. It's not going to take out the kernel, but your app might die. Deleting the log file and restarting is an option if that is what happens and you can tolerate that. You should test it to find out for sure, or make sure your log files are rotated and shipped out of the system periodically if you need it running constantly.
    – LawrenceC
    Oct 13 '14 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.