Re: [devel] ALT 9.1 Workstation K RC4

[Anton Farygin <rider@basealt.ru>]

On 09.03.2021 21:44, Mikhail Novosyolov wrote:
> 09.03.2021 21:36, Anton Farygin пишет:
>> On 09.03.2021 21:30, Mikhail Novosyolov wrote:
>>> 09.03.2021 21:28, Anton Farygin пишет:
>>>> On 09.03.2021 21:14, Mikhail Novosyolov wrote:
>>>>> 09.03.2021 16:51, Anton Farygin пишет:
>>>>>> On 09.03.2021 15:39, Mikhail Novosyolov wrote:
>>>>>>>> Там могут быть какие-то проблемы с этим?
>>>>>>> Конечно. Все, что зависит от network-online.target, сломается.
>>>>>> что ?
>>>>> cifs, nfs, и пр. сетевые шары (см. systemd-fstab-generator, что он автоматически проставляет в зависимость от network-online.target), nmbd
>>>> Отлично. зачем они должны быть доступны в момент загрузки ?
>>> nmbd , если правильно помню, будет ждать сколько-то, его кто-то будет ждать, там sd_notify используется.
>>>
>>> А шары попытаются смонтироваться, когда нет сети, и больше не будут пытаться, разве не так?
>>>
>> Это сильно зависит от настройки. Могут смонтироваться в момент обращения.
>>
>> Ещё не стоит забывать, что у нас помимо NetworkManager есть ещё и другие инструменты настройки сети.
>>
>> У меня, например, сервис NetworkManager-wait-online.service всегда тупит 30 секунд, хотя сеть поднята.
> Воот, это и было исходным вопросом у меня. Как вы это все разруливаете. Наконец понял, что вами двигало: несовместимость с etcnet.
помимо etcnet есть ещё и другие системы настройки сети.
>
> nm-online по, кажется, dbus запрашивает у NM статус соединения, плагин etcnet, может быть, мог бы ему помочь сообщать правильный статус сети для nm-online? Или, может быть, etcnet мог бы через sd_notify вызывать выполнение network-online.target в нужный момент


Нет, так не получится:

method call time=1615315703.723167 sender=:1.1070 -> 
destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=Hello
method return time=1615315703.723212 sender=org.freedesktop.DBus -> 
destination=:1.1070 serial=1 reply_serial=1
    string ":1.1070"
signal time=1615315703.723249 sender=org.freedesktop.DBus -> 
destination=(null destination) serial=2064 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameOwnerChanged
    string ":1.1070"
    string ""
    string ":1.1070"
signal time=1615315703.723294 sender=org.freedesktop.DBus -> 
destination=:1.1070 serial=2 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameAcquired
    string ":1.1070"
method call time=1615315703.724393 sender=:1.1070 -> 
destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=AddMatch
    string 
"type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.NetworkManager'"
method return time=1615315703.724453 sender=org.freedesktop.DBus -> 
destination=:1.1070 serial=3 reply_serial=2
method call time=1615315703.724627 sender=:1.1070 -> 
destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=GetNameOwner
    string "org.freedesktop.NetworkManager"
error time=1615315703.724677 sender=org.freedesktop.DBus -> 
destination=:1.1070 error_name=org.freedesktop.DBus.Error.NameHasNoOwner 
reply_serial=3
    string "Could not get owner of name 
'org.freedesktop.NetworkManager': no such name"
signal time=1615315733.744327 sender=org.freedesktop.DBus -> 
destination=:1.1070 serial=5 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameLost
    string ":1.1070"
signal time=1615315733.744382 sender=org.freedesktop.DBus -> 
destination=(null destination) serial=2065 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameOwnerChanged
    string ":1.1070"
    string ":1.1070"
    string ""


>
> Мне кажется, systemd позволяет решить задачу ожидания сети в более-менее общем виде весьма неплохо.

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

вообще NetworkManager-daemon отлично удаляется из системы без видимых 
последствий.