1

I'm trying to debug something that I don't quite understand well.

I have setup an automount of an external drive with:

/etc/fstab UUID={RANDOM_UUID} /media/pi/Storage ext4 defaults,nofail,x-systemd.device-timeout=10s 0 0

I also have setup a docker image with a volume pointing to that drive, and the container saves some files there. But then the drive gets unmounted somehow and the docker container keeps writing but to the Raspberry Pi Storage.

With vcgencmd get_throttled I was able to see that I sometimes get undervoltage and that could be the main problem. I tried to setup an script that detects undervoltage and restart the Raspi, but this looks like not the proper solution.

Is there a native way of knowing when the unmount happens and stop the docker image from writting onto the Raspi storage?

German Casares
  • 113
  • 2

3 Answers3

1

Docker is a red herring here.

If you have code that writes to mounted storage YOU need to ensure that the storage is ACTUALLY mounted. Otherwise you will write to the mount point with undesirable consequences. I include such a test in my code.

The other issue you mention is a different problem. If mounted devices unmount it is usually a power related issue. Pi USB ports have limited current capacity - use of powered drives or hubs may help.

Milliways
  • 62,573
  • 32
  • 113
  • 225
0

That the writing continues once the mount is gone implies that it may be opening a file and writing as opposed to holding it open (although that's probably still not impossible). You should check the mount point when nothing is on it to see if any data has been left in that directory (although this doesn't matter much unless you want that data, or it is of sufficient volume to take up too much space on the SD card).

Is there a native way of knowing when the unmount happens and stop the docker image from writing onto the Raspi storage?

The ideal way to do this would be with udev or inotify but there is not much in normalising the scenario -- as Milliways points out, it is likely a power issue, but in any case it is something you need to remedy.

In the meantime here's something simple that could be run at intervals, presuming the mount point is /mnt/mydrive:

#!/bin/sh

mount | grep "/mnt/mydrive"
if [ $? -ne 0 ]; then
    # Whatever you want to do here if the mount is gone.
else
    sleep 30s
fi

The sleep 30s bit is a way of keeping this running at intervals, either run this in the foreground of a terminal or background it (./myscript &) and don't log out. Alternately you could run it via cron or whatever such mechanism you are comfortable with.

goldilocks
  • 60,325
  • 17
  • 117
  • 234
0

Your problem has several suspects, but your question has not provided enough information to eliminate any of them. Here are some ideas:

1. Your /etc/fstab option: x-systemd.device-timeout=10s

Why do you leave this in when you're trying to troubleshoot mount issues?

2. As suggested by both of the other answers: You should put some code in your docker container to test for the presence of the mount before attempting a write.

I'd suggest you take a look at findmnt to perform this test. Another tutorial reference on findmnt is found at HTG.

3. Awareness of the under-voltage condition

An interrupt would be the best way to get useful information on under-voltage events. But AFAIK, there is no way for us mortals to get an interrupt from the RPi (if it even exists) with stock hardware & closed-source firmware. There have been a few discussion threads at the sawmill on that - for example, but I'm not aware of anything useful. Without an interrupt, we are stuck with polling - as suggested in @goldilocks' answer - and its attendant lower time resolution.

But don't get discouraged by inadequate event time resolution. If you're getting regular reports of low voltage from the vcgencmd get_throttled reports, this is something you should address. In other words:

  • Get a better power supply
  • Use the shortest power leads possible
  • Use the heaviest AWG wiring available in your power leads
Other, fyi:

If you're interested in the "mechanics" of the Low-Voltage warning, there are some details in this answer that may be of interest. There's enough information here to enable you to do a real-time capture of a low-voltage event using a simple voltage comparator (e.g. to generate an interrupt) - or with an oscilloscope. But again, I don't recommend that if vcgencmd get_throttled has informed you that these low voltage events are happening as you've already got the evidence you need to pursue a remedy to your power supply issues.

Seamus
  • 23,558
  • 5
  • 42
  • 83