Неможливо перезавантажити / повернути лише до читання після оновлення пакета

Я використовую Debian Stretch. Мій кореневий розділ змонтований read-only. Тільки коли я встановлюю або модернізую пакети, /перераховується read-write(за допомогою apt гака), а потім повертається назад до ro.

Іноді після оновлення пакету я не в змозі /повернутись лише до читання:

mount -o remount,ro /
mount: / is busy

У старих версіях Debian (Wheezy) я міг перелічити відкриті файли, від’єднані з lsof:

 lsof +L1

або, точніше, файли, які не дозволяють /перераховуватись до ro:

{ lsof +L1 ; lsof|sed -n '/SYSV/d; /DEL|(path /p;' ; } | grep -Ev '/(dev|home|tmp|var)'

Однак на Debian Stretch lsof +L1не вказано жодного файлу.

Я не бачу якихось - яких змін +|-Lв man lsofтому , що б пояснити , чому він перестав працювати.

Чому lsof + L1 більше не перераховує відкриті файли, від’єднані від зв’язку?

Як я можу перерахувати ті файли, які перешкоджають / перераховуються лише для читання?

ОНОВЛЕННЯ

Я зупинив всі процеси , які можуть бути зупинені, і тільки initі по- getty, як і раніше працює, але я до сих пір не можу перемонтування /до ro.

Як я можу перерахувати ті файли, які перешкоджають / перераховуються лише для читання?

А) fuserможна знайти в psmiscупаковці; це випадок використання, коли я знаходжу fuserблиски & є кориснішим ніж lsof.

# fuser -v -m / 2>&1 | grep '[Ff]r.e'

Це покаже всі процеси, у яких файли відкриті / для читання (f) та запису (F). Файли, які заважають / не перераховуються лише для читання, - це файли, відкриті для запису (F).

Убийте процеси, які виконуються у виконанні з файлами кореневого каталогу, відкритими для запису ., Тобто

# for fupid in $(fuser -v -m / 2>&1 | grep Fr.e | awk '{print $2}'); do kill $fupid; done

Це вище systemdзауважень із застереженням. Якщо systemdє, initто fuserпобачимо це і є інші міркування. З systemdроботою, він може (перо) запуск процесів за вашу спину, навіть якщо вони тільки що були виявлені і вбиті fuser. systemdнабагато досконаліший, ніж традиційний sysvinit.

B) ОНОВЛЕННЯ в описі зазначає, що система має лише ... initі gettyвсе ще працює ...

Я бачу коментар, який говорить, що система не використовує systemd, а використовує init. На розтяжку, systemd є init . У коментарі прямо не сказано sysvinit, тому я припускаю, що система, про яку йдеться, може використовувати розтягнення systemdза замовчуванням init. Або інші люди, які натрапляють на цю посаду, які використовують розтяжки systemd, вважають цю частину корисною.

На Wiki Debian ,

Процесом ініціалізації системи керує демон init. У стисканні та більш ранніх версіях цей демон надається пакетом sysvinit, і альтернативи не підтримуються. У хрипі , демон за замовчуванням init демон все ще єsysvinit , але "попередній перегляд технологій" systemd доступний. У Jessie і протягу , система ініціалізації за замовчуваннямsystemd , але перемикання на Sysvinit підтримується.

Оскільки Джессі, повністю підтримується лише systemd; sysvinit здебільшого підтримується, але пакунки Debian не повинні надавати сценарії запуску sysvinit. runit також упакований, але не отримав такого ж рівня тестування та підтримки, як інші, і наразі не підтримується як PID 1.

Під час systemdзапуску є кілька додаткових кроків, які потрібно зробити, щоб звільнитись / щоб її можна було повторно змінити.

Ймовірно, system.sliceце проведення відкритих файлів для systemd-journald.serviceабо systemd-udevd.service(обидва з яких мають залежність сокета). Або, якщо NetworkManagerвін запущений, він може відновлюватись, dhclientякий пише оренду в / var / ... (& / var / не завжди є власним пристроєм) тощо, fuserможе виявити & ви вбити, dhclientале NetworkManagerзапустить його відразу ж резервного копіювання.

Мораль - багато речей, які автоматизовані, що могли б "захотіти" / (і тим більше з " systemd).

Напевно, якщо це можливо, systemdеквівалент рівня 1 запуску відповідає rescue.target(і runlevel1.targetє символічним посиланням на rescue.target).

1) Почніть з ізоляції системи до rescue.target

# systemctl isolate rescue.target

Він повинен запропонувати вам ввести кореневий пароль; дотримуйтесь інструкцій на екрані.

2) На рятувальній оболонці з’ясуйте, що хоче /.

# systemctl show -p Wants /

Як правило, це system.slice; зупинити все, що хоче /. напр

# systemctl stop system.slice

3) На даний момент перерахунок не повинен звітувати mount: / is busyі mount -o remount,ro / повинен працювати. Якщо ні, перевірте ще раз fuser.

4) FWIW; Я також бачив випадки umountвідмов, коли / якщо інший пристрій встановлено в підкаталозі іншого монтажу, тобто вкладених кріплень. Наприклад, umount /не вдасться, якщо / var / або / boot / знаходиться на іншому пристрої (і встановлено). Хоча mount -o remount,ro /в цьому випадку все-таки має працювати.

lsblk може бути корисним для візуалізації вкладених кріплень.

Чому lsof + L1 більше не перераховує відкриті файли, від’єднані від зв’язку?

Оскільки вони недоступні (сокети або більшість FIFO та труб), вони більше не відкривають файли (батьківський процес закрив дескриптор файлу), або ж у них (досі) кількість посилань перевищує 1.

людина lsof (8) детальніше ...

+ | -L [l]

Ця опція дозволяє ('+') або відключає ('-') перелік лічильників файлових посилань, де вони доступні - наприклад, вони недоступні для розеток або більшості FIFO та труб.

Коли + L вказано без наступного номера, усі лінки посилаються на список. Коли -L задано (за замовчуванням), кількість посилань не відображатиметься.

Коли + L супроводжується номером, у списку будуть лише файли, що мають кількість посилань, менших за це число . (Ніяке число не може слідувати -L.) Специфікація форми '' + L1 '' вибере відкриті файли, від’єднані. Специфікація форми +aL1 <file_system>дозволить вибрати від’єднані відкриті файли у зазначеній файловій системі.

Ви /procвстановили?

Очевидно, що хтось, хто піклується про те, щоб /більшу частину часу встановлювали лише для читання, я можу собі уявити, що ви також можете не встановлювати файли Profs. Але profs потрібен для lsofпошуку відкритих файлів.

Файли, відкриті процесами, відкриваються ядром через символічні посилання в procfs. Каталоги /proc/<pid>/fdмістять символьне посилання для кожного файлу, який відкрито. Назва символьних посилань - це номери дескрипторів файлів, а шлях, на який посилається символьне посилання, - це шлях до файлу.

Символьні посилання, що звисають, залишаються /procвідкритими для вже відкритих файлів. І посилається шлях до файлу перейменовується на кінець "(видалено)".

Що lsof +L1насправді нічим не відрізняється від швидкого однолінійного типу:

stat -c%N /proc/[0-9]*/fd/* | grep deleted

Отже, ви можете скористатися аналогічним одноклассником, щоб перелічити всі відкриті файли, які можуть перешкодити переробці кореневої файлової системи (за умови роботи /proc).

Однак якщо ви зробили / зробили /procвстановлення, єдині інші причини, про які я можу подумати, - це помилки ... Так чи інакше, FYI, у моїй теперішній системі Debian Stretch. lsof +L1працює як очікувалося.

bash# lsb_release -d
Description:    Debian GNU/Linux 9.5 (stretch)

bash# uname -a
Linux bwp-249-8 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

bash# lsof -v
lsof version information:
    revision: 4.89
    [...]

Я міг відтворити цю проблему лише один раз і вирішив її просто за mountдопомогою параметра -n .

Цитуючи man mount :

-n, --no-mtab
      Mount without writing in /etc/mtab.  This is necessary for example when /etc is on a read-only filesystem.

Самі mountпрограми, що відкривають файли (файли) для запису в кореневу файлову систему, звучали як правдоподібне пояснення для мене. Конкретно mountпише, /etc/mtabзрештою і /etcчасто є частиною кореневої файлової системи. Однак я не зміг відтворити його знову на тій же машині після того, як я це зробив один раз ...

Чи може це вирішити вашу проблему?

Без видимості у вашій системі дуже важко точно сказати, в чому проблема. Зауваження та попередні відповіді - це добре початок.

З цього приводу я б повернувся до кінця через вікі Debian, який описує prereq для монтажу / читання лише.

Посилання на документацію тут: https://wiki.debian.org/ReadonlyRoot

Великий я проведу вас сюди:

1 - є конкретні місця під /, які потрібно читати записом. На підставі документації це виглядає приблизно так:

ваші блокові пристрої, ймовірно, будуть різними, залежно від конфігурації вашої пам’яті для зберігання даних (розділів, lvm без розділів і т. д.), але головна ідея полягає в тому, що вам потрібно, щоб ці 4 точки кріплення мали їх наступну змонтовану файлову систему, щоб мати можливість встановлення RW.

2 - в / etc є ряд спеціальних файлів, для яких потрібно або створити символічне посилання, або здійснити якусь іншу зміну (конкретно детальніше у прив'язаній статті). Вони можуть бути, а можуть і не застосовуватися залежно від того, які програми працює ваш Linux-сервер. деякі файли можуть навіть не існувати на вашій машині, але я включив все в документи. Майте на увазі, я настійно рекомендую вносити ці зміни ВИНАХІДЕ, якщо ви вбили кроку процесу. Ось шляхи прямо з вікі Debian:

• adjtime
• init.d / alsa-utils
• / etc / courier / shared / index
• будь-які файли стану чашок ,lasses.conf, cupsd.conf, printers.conf subscriptions.conf
• /etc/lvm/lvm.conf
• mtab (схоже, ви намагалися вирішити питання, встановивши прапор -n прапор)
• мережа / run (використовується ifup та ifdown, в стисканні. може не застосовуватися до розтягування, ymmv)
• нологін
• разреш.конф
• і файли passwd, і тіні
• samba / dhcp.conf
• смоктати
• удев

Після того, як ви перевірили все вищезазначене і підтвердили, що вони відповідають специфікаціям у вікі, наступне, що потрібно перевірити, - /etc/apt/apt.conf

DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro / || true"; };
}; 

виходячи з вашої помилки, остання річ, яку ви можете перевірити, виходячи з документації, походить із наведеного нижче:

"Після оновлення пакетів, можливо, ви зіткнетеся з проблемою, що програма монтажу відмовляється перезавантажувати файлову систему, що читає лише те, що" / зайнято ". Це викликано видаленими файлами, вони все ще використовуються процесом. Щоб дізнатися, які процеси використовують видалені файли, використовуйте інструмент checkrestart (1) з пакета debian-goodies або скористайтеся наступною командою. Часто це демони, що використовують оновлені бібліотеки. доведеться перезапустити їх, щоб випустити файли. "

команда, надана в документі:

{lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;'} |grep -Ev '/(dev|home|tmp|var)'

Не знаючи вашої точної конфігурації файлової системи, розділення та конфігурації пристроїв зберігання, важко дати вам ще багато чого дотримуватися. Я б почав із повернення назад і повторної перевірки ваших пререкцій у документації (і описаної вище).