Bug 37568 - Failed unmounting Runtime Directory
Summary: Failed unmounting Runtime Directory
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: systemd (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on: 35106
Blocks:
  Show dependency tree
 
Reported: 2019-12-03 16:24 MSK by Ivan A. Melnikov
Modified: 2019-12-04 18:10 MSK (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan A. Melnikov 2019-12-03 16:24:27 MSK 
При тестировании регулярок на mipsel и rpi было замечено, что при выключении иногда появляется в логах следующее:

[  OK  ] Stopped target Local File Systems.
         Unmounting /tmp...
         Unmounting Lock Directory...
         Unmounting Runtime Directory...
[  OK  ] Unmounted /tmp.
[  OK  ] Unmounted Lock Directory.
[FAILED] Failed unmounting Runtime Directory.
[  OK  ] Stopped target Local File Systems (Pre).
[  OK  ] Stopped target Swap.

На BFK 3.1 (mipsel) воспроизводится стабильно, при каждом выключении/перезагрузке.
Comment 1 Ivan A. Melnikov 2019-12-03 16:27:50 MSK 
При помощи пары грязных хаков удалось получить вывод lsof /run сразу после неудачного отмонтирования:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd      1 root   26u  FIFO   0,15      0t0 5961 /run/initctl
systemd      1 root   66r   REG   0,15     1536 2195 /var/run/utmp
systemd-j 2745 root  mem    REG   0,15        8 7545 /run/systemd/journal/kernel-seqnum

Похоже, виновата часть systemd, которая держит /var/run/utmp в этот момент.

На x86_64 я этого вроде не вижу (но там всё очень быстро пролетает...). Дмитрий, Антон, уточните пожалуйста, где эта проблема замечена.
Comment 2 Антон Мидюков 2019-12-03 16:35:46 MSK 
(В ответ на комментарий №0)
>На BFK 3.1 (mipsel) воспроизводится стабильно, при каждом
выключении/перезагрузке.

Стабильность это очень хорошо. Попробуй превратить /var/run в симлинк:
rm -fr /var/run && ln -s ../run /var/run

Будет ли проблема воспроизводиться после этого?
Comment 3 Ivan A. Melnikov 2019-12-03 17:03:37 MSK 
(In reply to comment #2)
> rm -fr /var/run 

Очень плохая идея делать так на живой системе. Система после этого перестанет быть живой, по крайней мере до перезагрузки.

Но мысль я понял и попробовал, примонтировав раздел на другую машину.

> Будет ли проблема воспроизводиться после этого?

Не должна. Проблема именно в отмонтировании bind-mount /var/run, который в случае если /var/run симлинк не делается.

Я проверил -- и правда, не воспроизводится.
Comment 4 Антон Мидюков 2019-12-03 17:08:49 MSK 
(В ответ на комментарий №3)
> (In reply to comment #2)
> > rm -fr /var/run 
> 
> Очень плохая идея делать так на живой системе. Система после этого перестанет
> быть живой, по крайней мере до перезагрузки.

Разумеется. После перезагрузки, как правило, всё ок :-)

> 
> Но мысль я понял и попробовал, примонтировав раздел на другую машину.
> 
> > Будет ли проблема воспроизводиться после этого?
> 
> Не должна. Проблема именно в отмонтировании bind-mount /var/run, который в
> случае если /var/run симлинк не делается.
> 
> Я проверил -- и правда, не воспроизводится.

Тогда переходим на симлинк.
Comment 5 Ivan A. Melnikov 2019-12-03 17:49:28 MSK 
(In reply to comment #1)
> Похоже, виновата часть systemd, которая держит /var/run/utmp в этот момент.

Из чисто образовательного интереса всё-таки запишу, что путь /var/run/utmp приходит в systemd из /usr/include/paths.h (макрос _PATH_UTMP), из пакета glibc-devel. В федоре, в glibc-headers-2.30.9000-21.fc32.x86_64.rpm, этот макрос имеет такое же значение.
Comment 6 Alexey Shabalin 2019-12-04 18:10:00 MSK 
Используйте симлинк /var/run -> /run и будет все хорошо.