Marcelo Laia <[email protected]> wrote: > Hello everyone, > > I'm designing a logging system on Debian Testing and would appreciate > some advice regarding a failure scenario that I recently became aware > of. > > My initial idea is quite simple: > > - Debian Testing > - rsyslog > - Log files stored on an external USB SSD > - The root filesystem should remain as untouched as possible, while > the SSD receives all log writes. > > While discussing this design elsewhere, someone pointed out an issue > that I had not considered. > > If the USB SSD is unexpectedly disconnected, the USB bus resets, or > the filesystem becomes unmounted for any reason, the mount point > directory still exists. As I understand it, applications may continue > writing to that directory, which now belongs to the underlying root > filesystem. On systems using flash storage, this could eventually > wear out the internal storage without immediately being noticed. > > My first thought was to periodically check /proc/mounts (or > /proc/self/mountinfo) with a small script and immediately stop rsyslog > if the filesystem is no longer mounted. This would probably work, but > it feels like I might be reinventing something that Linux or Debian > already provides. > > So my questions are: > > 1. Is there a standard or recommended Debian/Linux approach to prevent > applications from silently writing to the underlying directory > after a mounted filesystem disappears? > 2. Are there existing mechanisms in systemd, mount units, udev, > rsyslog, or elsewhere that are intended to handle this situation? > 3. How would you implement a robust solution for this type of logging > system? > > I'm not looking for a centralized log server in this particular > project. The goal is simply to make local logging to an external SSD > as reliable as possible while protecting the root filesystem from > unintended writes. > > Any suggestions or references to established best practices would be > greatly appreciated. > > Thank you very much.
What I generally do is just make the mount point read-only. So if the mount is not there for some reason, nothing can write to the underlying filesystem in that place.
