I have an weird challenge from on my Debian 8 box.

The background is I want to mount some directories as tmpfs, to avoid physical IO (disk wakeup / flash wear).

Probably I should just mount a separate tmpfs for each directory. However what I tried first was bind-mounts under /tmp/mnts. (My previous task was to move IO from disk to a small flash storage, to avoid spinups, so I just tried using the same pattern).

So I want to create directories on the tmpfs at boot time. I.e. systemd-tmpfiles. And then bind-mount them in various places under /var.

# /etc/tmpfiles.d/tmpfs-mnts.conf snippet
# Type Path    Mode UID  GID  Age Argument
d /tmp/mnts/var-lib-icinga-spool-checkresults 0750 nagios nagios -

# /etc/fstab snippet
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/tmp/mnts/var-lib-icinga-spool-checkresults /var/lib/icinga/spool/checkresults none bind

systemd-tmpfiles --create + mount -a works fine. But it doesn't work at boot time, so there's a race condition or something. But the failure is a bit interesting - findmnt shows the source directory has been deleted.

# findmnt|grep /var/lib/icinga/spool/checkresults
└─/var/lib/icinga/spool/checkresults                     tmpfs[/mnts/var-lib-icinga-spool-checkresults//deleted] tmpfs       rw
# cd /var/lib/icinga/spool/checkresults/
# mkdir ./test
mkdir: cannot create directory ‘./test’: No such file or directory
# ls --inode /tmp/mnts
7414 var-lib-icinga-spool-checkresults
# ls --inode /var/lib/icinga/spool/
6254 checkresults

So it looks like

  1. The mount happened correctly after systemd-tmpfiles created the source directory
  2. systemd-tmpfiles then deleted the source directory
  3. You're allowed to delete the source directory of a bind mount (?!)
  4. systemd-tmpfiles then created the source directory a second time

I guess there's a number of questions. Can we rely on 1) working? Could 1) still work if something other than systemd-tmpfiles created the source directory? What's the reason for 2) and 4) happening? And what's up with 3), has it always been like that?

  • I just lost files to that mistake when I was trying to bind some game's data from my SSD for faster load times... somehow systemd got the order right, but now the files are not only gone, but seemingly unrecoverable (tried phototrec, scalpel etc...) waiting for a solution
    – TheSola10
    May 9 '17 at 17:31

bind is unreliable when defined in fstab on a system with systemd. Systemd parses the fstab and tries to work out what order to mount and bind things in. From my own experience it gets this wrong 100% of the time. Best option is to move all you binds out of fstab and make you own xxx.mount system files for systemd. That was you gain controo over the order etc.

  • Interesting, is that behavior documented somewhere?
    – phk
    Oct 23 '16 at 15:38
  • This can be dealt with by using the extended mount options for systemd. You can provide dependencies this way. Take a look at man systemd.mount, specifically the parts about x-systemd.requires.
    – siride
    Jun 12 '17 at 21:42

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.