Невозможно удалить файлы в общей файловой системе

Сегодня во время развертывания приложения Linux для контейнеров приложение начало давать сбой и так и не появилось. Изучая журналы в Kudu, я увидел, что приложение не запускается, потому что во время установки зависимостей программа вылетает при попытке удалить файл.

Попытка удалить файлы вручную продолжает вылетать:

/home/site/wwwroot>ls -la libs/lxml
total 6868
drwxrwxrwx 2 nobody nogroup    4096 Oct 28 01:13 .
drwxrwxrwx 2 nobody nogroup   16384 Oct 28 01:23 ..
-rwxrwxrwx 1 nobody nogroup  304689 Oct 27 20:09 _elementpath.cpython-36m-x86_64-linux-gnu.so
-rwxrwxrwx 1 nobody nogroup 6704624 Oct 27 20:09 etree.cpython-36m-x86_64-linux-gnu.so
/home/site/wwwroot>rm -Rf libs
rm: cannot remove 'libs/lxml': Directory not empty
rm: cannot remove 'libs/newrelic/core': Directory not empty
rm: cannot remove 'libs/newrelic/packages/wrapt': Directory not empty

/home/site/wwwroot>rm -R libs
rm: cannot remove 'libs/lxml/etree.cpython-36m-x86_64-linux-gnu.so': No such file or directory
rm: cannot remove 'libs/lxml/_elementpath.cpython-36m-x86_64-linux-gnu.so': No such file or directory
rm: cannot remove 'libs/newrelic/core/_thread_utilization.cpython-36m-x86_64-linux-gnu.so': No such file or directory
rm: cannot remove 'libs/newrelic/packages/wrapt/_wrappers.cpython-36m-x86_64-linux-gnu.so': No such file or directory

Я «остановил» приложение, но файлы по-прежнему невозможно удалить.

Если не считать удаления и повторного создания приложения, какие у меня есть варианты, чтобы снова запустить приложение?

Изменить: я попытался использовать rm -rf, как было предложено, но, поскольку -r и -R — это один и тот же вариант, разницы нет:

/home/site/wwwroot>ls -la libs
total 16
drwxrwxrwx 2 nobody nogroup 16384 Oct 28 01:23 .
drwxrwxrwx 2 nobody nogroup     0 Sep 10 03:51 ..
drwxrwxrwx 2 nobody nogroup     0 Oct 28 01:13 lxml
drwxrwxrwx 2 nobody nogroup     0 Oct 28 01:13 newrelic
/home/site/wwwroot>rm -rf libs
rm: cannot remove 'libs/lxml': Directory not empty
rm: cannot remove 'libs/newrelic/core': Directory not empty
rm: cannot remove 'libs/newrelic/packages/wrapt': Directory not empty

/home/site/wwwroot>rm -rf libs
rm: cannot remove 'libs/lxml': Directory not empty
rm: cannot remove 'libs/newrelic/core': Directory not empty
rm: cannot remove 'libs/newrelic/packages/wrapt': Directory not empty

Я не могу использовать параметр SSH, так как использую python:3 в качестве контейнера (без настройки Azure).

В какой-то момент (в этом приложении) я попытался использовать контейнер, настроенный для Azure источник которого находится здесь. Все, что делает контейнер, — это добавляет дополнительный шаг запуска службы SSH во время запуска приложения, поэтому маловероятно, что он причастен к текущему сбою.

Изменить: я обновил приложение, чтобы использовать контейнер jaraco/python-azure (и исправил ошибку в этом контейнере). Я смог подключиться к контейнеру приложения по SSH на короткое время, в течение которого я попытался установить lsof, но до завершения этой команды соединение SSH было отключено, я подозреваю, что контейнер докера закрывается из-за невозможности удалить файлы.

С тех пор мне не удалось повторно подключиться через SSH, так как я получаю внутренние ошибки сервера из конечной точки webssh:

внутренняя ошибка сервера в webssh

Я попытался использовать другой файл запуска для контейнера: init_container.sh bash -c \"sleep 300\", чтобы он мог вращаться в течение 5 минут, пока я подключаюсь к нему по ssh, но даже когда я это сделал, я не мог подключиться к нему по SSH, и я получил только 503 ошибки от webssh конечная точка, хотя в диагностической консоли я вижу, что она запускает образ докера с соответствующими командами.

Я также попытался обновить файл запуска до init_container.sh rm -rf /home/site/wwwroot/libs/*, но с помощью диагностической консоли я вижу, что та же ошибка возникает в контейнере приложения:

2017-10-31 02:36:40.629 INFO - Issuing docker pull: imagename =jaraco/python-azure:latest
2017-10-31 02:36:40.668 INFO - Issuing docker pull: imagename =jaraco/python-azure:latest 
2017-10-31 02:36:40.709 INFO - Issuing docker pull jaraco/python-azure:latest 
2017-10-31 02:36:41.835 INFO - docker pull returned STDOUT>> latest: Pulling from jaraco/python-azure
Digest: sha256:589b1150b8b5893662a9dc7d0919e577cb2a95fcb0524fd1fffd7e5d8122b261
Status: Image is up to date for jaraco/python-azure:latest 
2017-10-31 02:36:41.855 INFO - Starting container for site 
2017-10-31 02:36:41.856 INFO - docker run -d -p 28374:80 --name APPNAME-dev_0 -e PORT=80 -e WEBSITE_SITE_NAME=APPNAME-dev -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=110c23d861dcaa09836ed00f278d29dc4b913a207c2d9dd4ed54366e3c2f6a3a -e HTTP_LOGGING_ENABLED=1 jaraco/python-azure:latest init_container.sh rm -rf /home/site/wwwroot/libs/*

2017-10-31 02:36:47.946 INFO - Container logs 
2017-10-31T02:36:42.675769119Z Starting OpenBSD Secure Shell server: sshd. 
2017-10-31T02:36:44.736417871Z rm: cannot remove ‘/home/site/wwwroot/libs/lxml’: Directory not empty
2017-10-31T02:36:45.596986651Z rm: cannot remove ‘/home/site/wwwroot/libs/newrelic/core’: Directory not empty
2017-10-31T02:36:45.649171980Z rm: cannot remove ‘/home/site/wwwroot/libs/newrelic/packages/wrapt’: Directory not empty
2017-10-31 02:36:47.947 ERROR - Container APPNAME-dev_0 for site APPNAME-dev has exited, failing site start

Я теряю надежду. Любые другие варианты?

Изменить: изменение плана службы приложений с S1 на S2, отправка запроса в службу (чтобы инициировать перемещение), а затем переключение приложения обратно на S1 устранило проблему, но только временно. Когда позже на неделе возобновился трафик к службе, она некоторое время работала, а затем снова начала давать сбой с сообщением «Служба недоступна». Проверив логи, та же ошибка вернулась. Во время запуска приложение пытается удалить эти файлы, но, поскольку эти файлы явно используются, удаление и последующие шаги запуска завершатся неудачно. Хуже того, изменение плана службы приложений, которое, казалось, решило проблему на прошлой неделе, на этот раз кажется недостаточным обходным путем. Кроме того, изменение размера плана службы приложений, хотя и является эффективным, также имеет непредвиденные побочные эффекты, такие как отключение других приложений в этом плане службы.

Я подозреваю, что некоторые детали реализации общей файловой системы (смонтированной в /home) приводят к тому, что открытые файлы блокируются и, следовательно, не могут быть удалены в процессе развертывания или при запуске другого экземпляра или вручную.

Я почти уверен, что мой единственный вариант — не использовать общую файловую систему для любых файлов, которые могут быть открыты приложением (например, общие библиотеки).

Изменить: в попытке минимально воспроизвести проблему я создал это веб-приложение и развернули его здесь. В настоящее время работает нормально. Я ожидаю, что после того, как он останется бездействующим в течение некоторого времени, он будет сброшен, и последующий запрос вызовет его повторный запуск, и он потерпит неудачу. Я отчитаюсь, эффективно это или нет.

Изменить: мне не удалось воспроизвести проблему в новом веб-приложении. Я попытался оставить приложение бездействующим на 24 часа, чтобы посмотреть, не вызовет ли это проблему. Я также пытался явно понизить зависимость «newrelic» (которая содержит одну из общих библиотек .so) и запускать и останавливать веб-приложение, чтобы снова запустить сценарий «запуска». Но что бы я ни делал, приложение запускается нормально. Теперь я думаю, что мне следует просто стереть и перестроить мое неудачное производственное приложение и посмотреть, исчезнет ли проблема.


person Jason R. Coombs    schedule 28.10.2017    source источник
comment
Вы пытаетесь rm -rf libs?   -  person Shui shengbao    schedule 30.10.2017
comment
Когда вы используете консоль отладки Kudu, вы можете попробовать SSH управлять своим веб-приложением как пользователь root. Ваш путь - это путь пользователя, я думаю, вы могли бы удалить каталог.   -  person Shui shengbao    schedule 30.10.2017


Ответы (2)


В консоли Kudu вы можете попробовать SSH ваше веб-приложение. Вы входите в систему как пользователь root, вы можете удалить эти файлы и каталоги.

Если вам не нужен каталог libs/lxml, я предлагаю вам удалить его, выполнив следующие действия.

cd /home/site/wwwroot/libs/lxml
rm -rf *
cd ..
rm -rf * ## rm -rf lxml
cd ..
rm -rf libs

Обновлять:

Изменение размера плана службы приложений изменит ваше веб-приложение на другой хост, возможно, это решит эту проблему.

person Shui shengbao    schedule 30.10.2017
comment
Я не могу попробовать SSH без развертывания другого образа. Могу ли я ожидать, что эти команды будут выполняться в контейнере приложения, где они не работают в контейнере kudu? Должен ли я выполнить развертывание с другим образом и попробовать маршрут SSH? - person Jason R. Coombs; 30.10.2017
comment
@JasonR.Coombs Согласно журналу ошибок, кажется, что есть некоторые .file, которые ваш скрипт не смог удалить. Я предлагаю вам изменить свой сценарий cd /home/site/wwwroot/libs/lxml && rm -rf *. * удалит все файлы. - person Shui shengbao; 31.10.2017
comment
@JasonR.Coombs Should I deploy with a different image and try the SSH route? Может быть, вы могли бы попробовать. Когда вы подключаетесь к изображению по ssh, вы можете попробовать apt-get install lsof и использовать lsof etree.cpython-36m-x86_64-linux-gnu.so независимо от того, используются ли файлы. - person Shui shengbao; 31.10.2017
comment
Я пробовал эти вещи, но безуспешно. Кажется, что-то мешает удалить эти файлы либо из контейнера kudu, либо из контейнера приложения (см. обновления выше). - person Jason R. Coombs; 31.10.2017
comment
Да. Kudu bash — это диагностическая консоль, в которой я изучал журналы и выдавал команды. - person Jason R. Coombs; 31.10.2017
comment
Давайте продолжим обсуждение в чате. - person Shui shengbao; 31.10.2017
comment
Согласно журналу ошибок, возможно, в вашей файловой системе изображения есть ошибка, возможно, вы проверяете ее исправление. fsck -AR -y. Но я не уверен. См. вопрос. - person Shui shengbao; 31.10.2017
comment
Знаете ли вы, что /home — это смонтированная файловая система, размещенная в Azure? Я почти уверен, что не смогу его проверить или выполнить какое-либо другое обслуживание. - person Jason R. Coombs; 31.10.2017
comment
Я еще не решил проблему. Я открыл тикет с поддержкой Azure. Я запланировал звонок, чтобы поговорить с агентом завтра. По вашему совету я изменил размер плана службы приложений (увеличил его вдвое, а затем снова уменьшил). После этого я попытался удалить библиотеки, и команда успешно завершилась... так что, похоже, изменение размера каким-то образом разблокировало файлы. - person Jason R. Coombs; 03.11.2017
comment
@JasonR.Coombs Мой коллега сказал мне, что это может ответить на этот очень странный вопрос. Если вы измените размер, ваше веб-приложение переместится на другой хост. - person Shui shengbao; 03.11.2017
comment
Нет. Хотя на прошлой неделе это, по-видимому, работало, также возможно, что проблема решилась другим способом (возможно, из-за того, что приложение бездействовало, оно стало деинициализированным, что позволило разблокировать файлы). В любом случае, я только что изменил размер плана службы приложений, но по-прежнему не могу заставить приложение отвечать, и оно продолжает давать сбой с той же ошибкой, о которой сообщалось изначально. Я думаю, что мне придется переделать приложение. Что я, вероятно, могу сделать, так это создать версию этого приложения с открытым исходным кодом, которая минимально воспроизводит проблему. - person Jason R. Coombs; 08.11.2017
comment
@JasonR.Coombs Привет, ты нашел решение этой проблемы? - person Shui shengbao; 22.11.2017
comment
К сожалению, мы решили проблему, не полагаясь на контейнеры приложений (развернув контейнер вручную на виртуальной машине). Я считаю, что эту проблему также можно обойти, не используя общую файловую систему для любых файлов, которые приложение может держать открытыми (например, общие библиотеки/DLL). - person Jason R. Coombs; 25.11.2017

Похоже, это конструктивное ограничение веб-приложений Azure. Любые файлы в общей файловой системе, открытые приложением (даже только для чтения), не будут доступны для записи или удаления. Единственный вариант — перепроектировать приложение так, чтобы оно хранило такие файлы не в общей файловой системе.

Я подозреваю, что эта проблема усугубляется общей файловой системой, размещенной в Windows. В системе Unix файл обычно можно удалить, даже если он открыт другим процессом. Поэтому для пользователей Web Apps For Containers дополнительный сюрприз заключается в том, что файлы нельзя удалить, и поэтому они просто задерживаются без ошибки.

person Jason R. Coombs    schedule 25.11.2017