Re: [make-initrd] [PATCH 2/2] runtime: Fix console lock shadowing by /dev mount

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/17/26 12:45 PM, Alexey Gladkov wrote:
> On Fri, Oct 16, 2026 at 11:02:36PM +0300, Leonid Krivoshein wrote:
>> Привет!
>>
>>
>> On 10/16/26 3:06 PM, Alexey Gladkov wrote:
>>> /etc/rc.d/rc acquires an exclusive lock on /dev/console before starting
>>> runlevel services. When the mountfs service mounts devtmpfs over /dev,
>>> the original /dev/console inode on rootfs is shadowed by a new inode on
>>> devtmpfs. Consequently, rc holds the lock on the shadowed inode while
>>> processes started after mountfs lock the new /dev/console inode without
>>> waiting for rc to finish starting services. In particular, with the
>>> rdshell boot parameter, rootdelayd acquires the console lock and starts
>>> the emergency shell in the middle of runlevel 3 instead of after all
>>> services have started.
>>>
>>> Once the console lock is preserved across mountfs, the network-up init
>>> service deadlocks against its parent /etc/rc.d/rc because network-up
>>> requests a shared lock on the console while rc already holds an
>>> exclusive lock for the duration of the runlevel scripts.
>>>
>>> Use a dedicated /.initrd/console.lock file in /.initrd so the lock
>>> remains on the same inode across /dev mount operations, and drop the
>>> redundant lock acquisition from the synchronous network-up init script.
>>
>> Хорошо, что нашлось решение и есть в сообществе люди, умеющие не только
>> репортить баги, но и разбирающиеся в них, предлагающие патчи! Я всего-то
>> хотел уточнить, поскольку вносил изменения в свою документацию, а тут
>> столько всего поменялось. :-)
>>
>> Но есть вопросы к этим изменениям, см. ниже...
>>
>>
>>>
>>> Fixes: 598a4b241a4f ("Rewrite console locking")
>>> Reported-by: Leonid Krivoshein <klark.devel@gmail.com>
>>> Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
>>> ---
>>>    features/fsck/data/lib/uevent/handlers/040-mountdev         | 2 +-
>>>    features/luks/data/lib/uevent/handlers/085-luks             | 2 +-
>>>    features/network/data/etc/rc.d/init.d/network-up            | 3 ---
>>>    features/runtime/data/etc/rc.d/rc                           | 2 +-
>>>    features/runtime/data/init                                  | 1 +
>>>    .../runtime/data/lib/uevent/handlers/mount/900-localdev     | 2 +-
>>>    features/runtime/data/sbin/rootdelayd                       | 6 +++---
>>>    features/sshfsroot/data/lib/uevent/handlers/040-sshfsroot   | 2 +-
>>>    features/zfs/data/sbin/ueventd-zfs                          | 2 +-
>>>    9 files changed, 10 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/features/fsck/data/lib/uevent/handlers/040-mountdev b/features/fsck/data/lib/uevent/handlers/040-mountdev
>>> index 53208f0d..9e9f06ea 100755
>>> --- a/features/fsck/data/lib/uevent/handlers/040-mountdev
>>> +++ b/features/fsck/data/lib/uevent/handlers/040-mountdev
>>> @@ -56,7 +56,7 @@ handler()
>>>    }
>>>    exec 0</dev/console >/dev/console 2>&1
>>> -fd_lock 90 /dev/console
>>> +fd_lock 90 /.initrd/console.lock
>> Получается, здесь сначала выполняется открытие файла консоли, только потом
>> её захват. Не лучше ли наоборот или это непринципиально?
> 
> Это блокировка не открытия /dev/console, а записи в неё. Открыть и держать
> открытой её может кто угодно.
> 

По всем трём вопросам теперь понятно, спасибо! Однако замечу...


>> Коль блокировка консоли используется внутри make-initrd во многих местах,
>> нет ли смысла скрыть её внутреннюю реализацию как раз на случай таких
>> изменений? Что-то типа fd_lock_console() / fd_unlock_console().
> 
> Я этого не делал с самого начала в первую очередь из-за номера
> дескриптора. Для вызываемых утилит его иногда стоит закрывать по номеру.
> Хардкодить этот номер внутри функции и использовать магические числа в
> коде выше выглядит неправильно:
> 
>    fd_lock_console
>    rdshell "Emergency shell" 90<&-
>    fd_unlock_console
> 
> или
> 
>    fd_lock_console
>    rdshell "Emergency shell" $fd_console<&-
>    fd_unlock_console
> 
> выглядит криво.

а если так?

fd_lock_console
fd_locked_console rdshell "Emergency shell"
fd_unlock_console

# wrapper
fd_locked_console()
{
     "$@" $fd_console<&-
}



> Плюс если потребуется залочить ещё какой-то ресурс, то
> встанет проблема синхронизации номеров дескрипторов.
> 

Этой проблемы нет, если назначать номера дескрипторов динамически.


> Поэтому я решил не прятать эти аргументы и предоставить вызывающему
> больший контроль.
> 
>> Насколько безопасно использовать статически заданный дескриптор для этой
>> блокировки? Не лучше ли его определять динамически?
> 
> В шелле нет хорошего способа выбрать свободный дескриптор. Только перебор
> по /proc/self/fd/*. Это намного затратнее и требует смонтированного /proc.
> Всё это будет медленнее.
> 
> И опять же придётся делать целую библиотеку с выбором дескрптора,
> глобальной переменной, где этот номер будет жить.
> 

Есть вариант для bash >= 4.1. Причём, если делать это в субшеле, то даже 
необязательно закрывать файл, bash его сама закроет. Пример:

exec {fd_console}>/.initrd/console-fd.lock
echo "..." >&$fd_console
exec {fd_console}>&-

Только я не знаю, можно ли в случае make-initrd полагаться, что у bash 
версия не меньше 4.1, но на Альте данный код работает, проверил на p11.


> Без нужды я не вижу смысла такое городить.
> 

Да, тут тебе конечно видней.


-- 
WBR, Leonid Krivoshein.