bind mounts systemd не магически работают с systemd-tmpfiles?

У меня есть странный вызов из моего бокса Debian 8.

Фон – это то, что я хочу монтировать некоторые каталоги как tmpfs, чтобы избежать физического IO (извлечения диска / вспышки).

  • запустить исполняемый файл при загрузке
  • Debian - невозможно найти cdrom
  • apt-get не удалось найти обновления для сжатия Debian
  • Почему различная пунктуация в именах файлов пакета Debian vs source directory?
  • Когда bash прекратил экспорт SHELL?
  • Можно ли подключить локальный пакет-репо?
  • Вероятно, я должен просто установить отдельные tmpfs для каждого каталога. Однако то, что я пробовал первым, было bind-mounts под /tmp/mnts . (Моя предыдущая задача состояла в том, чтобы переместить IO с диска на небольшую флеш-память, чтобы избежать раскрутки, поэтому я просто попытался использовать один и тот же шаблон).

    Поэтому я хочу создавать каталоги на tmpfs во время загрузки. Т.е. systemd-tmpfiles. А затем привяжите их в разных местах под / 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 отлично работает. Но это не работает во время загрузки, поэтому есть состояние гонки или что-то в этом роде. Но сбой немного интересный – findmnt показывает, что исходный каталог удален.

     # 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 

    Так выглядит

    1. Смонтировано правильно, после того как systemd-tmpfiles создал исходный каталог
    2. systemd-tmpfiles затем удалил исходный каталог
    3. Вы можете удалить исходный каталог привязки (?!)
    4. systemd-tmpfiles затем создал исходный каталог во второй раз

    Наверное, есть ряд вопросов. Можем ли мы полагаться на 1) работу? Может ли 1) работать, если что-то другое, кроме systemd-tmpfiles, создало исходную директорию? В чем причина 2) и 4)? И что случилось с 3), всегда ли было так?

  • Динамические переменные в файлах модулей systemd
  • как сказать firefox отключиться от tty1?
  • Это плохая идея добавить себя в группу sudo?
  • Запуск сценария init.d создает «start-stop-daemon: not found»
  • Откуда система определяет временное имя хоста?
  • Команда сортировки в нескольких полях
  • One Solution collect form web for “bind mounts systemd не магически работают с systemd-tmpfiles?”

    привязка ненадежна при определении в fstab в системе с systemd. Systemd анализирует fstab и пытается выяснить, в каком порядке монтировать и связывать вещи. По собственному опыту он ошибается в 100% случаев. Лучший вариант – переместить все, что вы связываете, из fstab и создать собственные системные файлы xxx.mount для systemd. Это вы набрали противоречия над заказом и т. Д.

    Linux и Unix - лучшая ОС в мире.