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

Question

Во время развертывания приложения 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:

Я попытался использовать другой файл запуска для контейнера: 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), а также запустить и остановить веб-приложение, чтобы снова запустить скрипт "run". Но независимо от того, что я делаю, приложение запускается нормально. Теперь я думаю, что мне следует просто стереть и восстановить свое сбойное производственное приложение и посмотреть, исчезнет ли проблема.

Answer 1

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

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

Answer 2

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

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

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

Обновить:

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