mount и umount ведут себя по-разному при запуске под cron

429
Joshua Grigonis

Запуск CentOS 6 в AWS, и то, что я вижу, сбивает меня с толку.

Существует s3fsмонтирование, /etc/fstabкоторое иногда теряет способность читать и писать. У меня есть работа cron, которая отлично работала в течение нескольких месяцев, она просто проверяла, что монтирование было хорошим каждую минуту, и если оно потеряло соединение, оно просто umountи mountделило. Крепление чаще уходило без нагрузки, чем при реальной нагрузке, так что это было отличное решение.

По какой - то причине это перестало работать, и теперь машина придумать не в состоянии чтения / записи из доли, как и первое, что машины делают при загрузке после инициализации является umountи mountдоля.

Теперь ошибка, которую я получаю при попытке прочитать, такова:

cp: cannot open `/app/canary.txt' for reading: Input/output error 

В этом /var/log/messagesя вижу это:

kernel: s3fs[3077]: segfault at e66000 ip 00007f833663d94e sp 00007ffc849c5b18 error 4 in libc-2.12.so[7f83365b4000+18a000] 

Теперь, когда я запускаю тот же сценарий в консоли, что и root, он просто отлично работает. Разборка и установка привода и оставление его в рабочем состоянии.

Моим первым предположением было то, что что-то в окружающей среде вызывало разницу, поэтому я добавил source /root/.bash_profileв свой сценарий безрезультатно.

Строка в / etc / fstab является монстром, но это то, что мы нашли лучше всего работать после многих попыток тонкой настройки:

ourbucket /app fuse.s3fs _netdev,allow_other,endpoint=us-west-2,url=https://s3-us-west-2.amazonaws.com,use_path_request_style,use_sse,gid=1001,umask=0007,use_cache=/srv/s3fs,retries=20,parallel_count=30,connect_timeout=30,readwrite_timeout=60,stat_cache_expire=86400,max_stat_cache_size=100000 0 0 

Вот как выглядит cronfile:

* * * * * root /usr/bin/sudo /root/check_mount.sh 

Я попробовал это с и без sudo, поскольку я думал, что это может затронуть окружающую среду.

Я перепробовал множество вариантов сценария, но большинство этих команд использовались в тот или иной момент. Одна и та же проблема возникает независимо от того, какой тип umountя делаю.

\cp /app/canary.txt /tmp/canary.txt retVal=$? sleep 1 if [ $ -ne 0 ]; then echo "Copy failed, trying to umount" umount /app echo "umount returned $?" sleep 1 echo "Trying umount -f" umount -f /app echo "umount -f returned $?" sleep 1 echo "Trying fusermount -u" /usr/local/bin/fusermount -u /app echo "fusermount returned $?" sleep 1 echo "Trying to mount" mount /app echo "mount returned $?" sleep 1 echo "Trying copy after mount" \cp /app/canary.txt /tmp/canary.txt fi 

Этот сценарий был изначально python, с ключевыми частями, просто обстреливая os.system, но я хотел удалить это из уравнения. Это давало те же проблемы.

5
«Монтирование чаще уходило без нагрузки, чем при реальной нагрузке» - я думаю, что «autofs» может заменить ваш скрипт; однако я не могу сказать, решит ли это вашу проблему. Я пишу это только для того, чтобы вы знали, что такой инструмент существует, может быть, вы найдете его полезным. Kamil Maciorowski 5 лет назад 0

1 ответ на вопрос

4
Joshua Grigonis

Вот мое полное решение:

Сначала я визуально проверил Audit.log. Чтобы поймать правильные и только правильные вещи, я использовал audit2allowдля создания политики и правила принудительного использования типов.

grep mount /var/log/audit/audit.log | audit2allow -R -M mounts3fs 

Я говорю о горе, поэтому я получаю только правильные вещи.

Это создало файл mounts3fs.pp и mounts3fs.te . Mounts3fs.te выглядит следующим образом :

policy_module(mounts3fs, 1.0)  require { type file_t; type var_t; type mount_t; type cert_t; class dir { write remove_name add_name }; class file { create unlink link setattr }; }  #============= mount_t ============== #!!!! The source type 'mount_t' can write to a 'dir' of the following types: # user_home_t, etc_runtime_t, var_run_t, mount_var_run_t, mount_tmp_t, user_home_dir_t, etc_t, nfs_t, tmpfs_t, tmp_t, var_t  allow mount_t cert_t:dir { write remove_name add_name }; allow mount_t cert_t:file { create unlink }; allow mount_t file_t:dir { remove_name add_name }; allow mount_t file_t:file { unlink link setattr }; allow mount_t var_t:file link; 

Чтобы установить политику, я запускаю это:

semodule -i mounts3fs.pp 

Я обнаружил, что этого недостаточно для определенных операций, поэтому я создал дополнительную политику, например:

module s3fs 1.0;  require { type file_t; type mount_t; class dir create; class file create; }  #============= mount_t ==============  #!!!! This avc is allowed in the current policy allow mount_t file_t:dir create; allow mount_t file_t:file create; 

selinux все еще может пойти прямо в ад.

Я опубликую полное решение, как только оно у меня будет. По сути, `selinux` блокирует чтение / запись на подключенном томе. Joshua Grigonis 5 лет назад 2

Похожие вопросы