13.11.2019 14:36, Alex Moskalenko пишет: > > Здравствуйте. > > Есть система на p9 с sysvinit. На ней обновился libvirt c 5.6.0-alt1 > p9+236527.100.1.1 до 5.7.0-alt1 p9+238412.2000.8.2. После обновления > перестали работать утилиты управления (virsh, virt-manager) с > одинаковой диагностикой: > > > ошибка: не удалось подключиться к гипервизору > ошибка: Failed to connect socket to '/var/run/libvirt/libvirt-sock': > Нет такого файла или каталога > > > При этом сам libvirtd, его обвязка (virtlogd, virtlockd) и виртуальные > машины запускаются и работают. > > Было замечено, что после обновления все pid-файлы, сокеты и > соответствующие каталоги переехали из /var/run в /run. Но почему-то > virsh, virt-manager и т.п. по-прежнему пытаются подключиться к сокету > в /var/run. Где можно изменить путь до сокета для клиентов libvirt - > не нашел. В конфигах в /etc/libvirt все строчки с путями до сокетов > раскомментированы. Создание симлинков на сокеты в /var/run проблему > решает. > > > В связи с этим вопросы - почему это происходит и как правильно решить > проблему? Есть подозрение, что это из-за отсутствия systemd. Если это > так - то получается, что p9 даже в серверном варианте уже не полностью > работоспособен без systemd, и с этим нужно что-то делать. > Необходимо перейти на симлинки /var/run -> /run и /var/lock -> run/lock В новых инсталляциях переход производится постустановочным скриптом. > PS Видимо, пришло время даже в серверных вариантах переходить на > systemd с sysvinit.... > > > -- > WBR, Alex Moskalenko > > _______________________________________________ > Sysadmins mailing list > Sysadmins@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/sysadmins -- С уважением, Антон Мидюков <antohami@altlinux.org>
Антон Мидюков писал 13.11.2019 10:44:
> 13.11.2019 14:36, Alex Moskalenko пишет:
>> Есть система на p9 с sysvinit. На ней обновился libvirt c 5.6.0-alt1
>> p9+236527.100.1.1 до 5.7.0-alt1 p9+238412.2000.8.2. После обновления
>> перестали работать утилиты управления (virsh, virt-manager) с
>> одинаковой диагностикой:
>>
>>
>> ошибка: не удалось подключиться к гипервизору
>> ошибка: Failed to connect socket to '/var/run/libvirt/libvirt-sock':
>> Нет такого файла или каталога
> Необходимо перейти на симлинки /var/run -> /run и /var/lock -> run/lock
>
> В новых инсталляциях переход производится постустановочным скриптом.
Спасибо за быстрый ответ.
Я правильно понимаю, что нужно переместить текущее содержимое /var/lock
в /run/lock, /var/run в /run, удалить /var/{run,lock} и создать симлинки
/var/run->/run и /var/lock->/run/lock?
Система обновлялась с P8, в ней получается, это не было сделано
автоматически при апгрейде? У меня несколько таких систем, обновленных
p8->p9, это нужно сделать везде?
13.11.2019 15:02, Alex Moskalenko пишет: > Антон Мидюков писал 13.11.2019 10:44: >> 13.11.2019 14:36, Alex Moskalenko пишет: >>> Есть система на p9 с sysvinit. На ней обновился libvirt c 5.6.0-alt1 >>> p9+236527.100.1.1 до 5.7.0-alt1 p9+238412.2000.8.2. После обновления >>> перестали работать утилиты управления (virsh, virt-manager) с >>> одинаковой диагностикой: >>> >>> >>> ошибка: не удалось подключиться к гипервизору >>> ошибка: Failed to connect socket to '/var/run/libvirt/libvirt-sock': >>> Нет такого файла или каталога >> Необходимо перейти на симлинки /var/run -> /run и /var/lock -> run/lock >> >> В новых инсталляциях переход производится постустановочным скриптом. > > Спасибо за быстрый ответ. > Я правильно понимаю, что нужно переместить текущее содержимое > /var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и > создать симлинки /var/run->/run и /var/lock->/run/lock? > Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже установленные системы пользователи должны переводить сами, при необходимости. > Система обновлялась с P8, в ней получается, это не было сделано > автоматически при апгрейде? У меня несколько таких систем, обновленных > p8->p9, это нужно сделать везде? Желательно. > _______________________________________________ > Sysadmins mailing list > Sysadmins@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/sysadmins -- С уважением, Антон Мидюков <antohami@altlinux.org>
Антон Мидюков писал 13.11.2019 11:33:
>> Я правильно понимаю, что нужно переместить текущее содержимое
>> /var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и
>> создать симлинки /var/run->/run и /var/lock->/run/lock?
>>
> Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже
> установленные системы пользователи должны переводить сами, при
> необходимости.
Переместил содержимое и сделал симлинки, предварительно остановив и
запустив после создания симлинков тех, кто использовал /var/{run/lock}.
Сейчас так:
ls -l /var
итого 64
drwxr-xr-x 2 root root 4096 авг 28 2018 adm
drwxr-xr-x 10 root root 4096 авг 28 2018 cache
drwxr-xr-x 3 root root 4096 сен 30 12:55 db
dr-xr-xr-x 2 root root 4096 авг 28 2018 empty
drwxr-xr-x 6 root root 4096 июн 28 14:19 hasplm
drwxr-xr-x 32 root root 4096 ноя 12 17:23 lib
drwxr-xr-x 2 root root 4096 авг 28 2018 local
lrwxrwxrwx 1 root root 9 ноя 13 11:53 lock -> /run/lock
drwxr-xr-x 21 root root 4096 ноя 10 04:02 log
lrwxrwxrwx 1 root root 10 сен 12 15:25 mail -> spool/mail
drwxr-xr-x 2 root root 4096 авг 28 2018 nis
drwxr-x--- 2 root nobody 4096 авг 28 2018 nobody
drwxr-xr-x 2 root root 4096 авг 28 2018 opt
drwxr-xr-x 2 root root 4096 авг 28 2018 preserve
drwxr-xr-x 5 root root 4096 апр 29 2019 resolv
lrwxrwxrwx 1 root root 4 ноя 13 11:52 run -> /run
drwxr-xr-x 8 root root 4096 сен 12 15:27 spool
drwxrwxrwt 2 root root 4096 авг 28 2018 tmp
drwxr-xr-x 2 root root 4096 авг 28 2018 yp
Из использовавших файлы в /var/run оказались fail2ban, monit,
zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть каталоги,
которых нет в /run/lock. То же с /var/run и /run.
Мучает вопрос - после перезагрузки эти каталоги с нужными правами будут
созданы заново? Или это мусор, оставшийся в процессе обновлений системы?
Пока перезагрузиться и проверить не могу...
---
WBR, Alex Moskalenko
13.11.2019 16:53, Alex Moskalenko пишет: > Антон Мидюков писал 13.11.2019 11:33: >>> Я правильно понимаю, что нужно переместить текущее содержимое >>> /var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и >>> создать симлинки /var/run->/run и /var/lock->/run/lock? >>> >> Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже >> установленные системы пользователи должны переводить сами, при >> необходимости. > Переместил содержимое и сделал симлинки, предварительно остановив и > запустив после создания симлинков тех, кто использовал > /var/{run/lock}. Сейчас так: > ls -l /var > итого 64 > drwxr-xr-x 2 root root 4096 авг 28 2018 adm > drwxr-xr-x 10 root root 4096 авг 28 2018 cache > drwxr-xr-x 3 root root 4096 сен 30 12:55 db > dr-xr-xr-x 2 root root 4096 авг 28 2018 empty > drwxr-xr-x 6 root root 4096 июн 28 14:19 hasplm > drwxr-xr-x 32 root root 4096 ноя 12 17:23 lib > drwxr-xr-x 2 root root 4096 авг 28 2018 local > lrwxrwxrwx 1 root root 9 ноя 13 11:53 lock -> /run/lock > drwxr-xr-x 21 root root 4096 ноя 10 04:02 log > lrwxrwxrwx 1 root root 10 сен 12 15:25 mail -> spool/mail > drwxr-xr-x 2 root root 4096 авг 28 2018 nis > drwxr-x--- 2 root nobody 4096 авг 28 2018 nobody > drwxr-xr-x 2 root root 4096 авг 28 2018 opt > drwxr-xr-x 2 root root 4096 авг 28 2018 preserve > drwxr-xr-x 5 root root 4096 апр 29 2019 resolv > lrwxrwxrwx 1 root root 4 ноя 13 11:52 run -> /run > drwxr-xr-x 8 root root 4096 сен 12 15:27 spool > drwxrwxrwt 2 root root 4096 авг 28 2018 tmp > drwxr-xr-x 2 root root 4096 авг 28 2018 yp > > Из использовавших файлы в /var/run оказались fail2ban, monit, > zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть > каталоги, которых нет в /run/lock. То же с /var/run и /run. > Мучает вопрос - после перезагрузки эти каталоги с нужными правами > будут созданы заново? Или это мусор, оставшийся в процессе обновлений > системы? Пока перезагрузиться и проверить не могу... В /run будут созданы каталоги, которые прописаны в конфигах: /lib/tmpfiles.d/*.conf /etc/tmpfiles.d/*.conf Если какие-то пакеты всё ещё напрямую содержат каталоги в /var/run и не имеют конфигов tmpfiles.d, то на них нужно заводить баги и срочно исправлять. > --- > WBR, Alex Moskalenko > > _______________________________________________ > Sysadmins mailing list > Sysadmins@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/sysadmins -- С уважением, Антон Мидюков <antohami@altlinux.org>
Антон Мидюков писал 13.11.2019 13:32:
> 13.11.2019 16:53, Alex Moskalenko пишет:
>> Антон Мидюков писал 13.11.2019 11:33:
>>>> Я правильно понимаю, что нужно переместить текущее содержимое
>>>> /var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и
>>>> создать симлинки /var/run->/run и /var/lock->/run/lock?
>>>>
>>> Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже
>>> установленные системы пользователи должны переводить сами, при
>>> необходимости.
>> Переместил содержимое и сделал симлинки, предварительно остановив и
>> запустив после создания симлинков тех, кто использовал
>> /var/{run/lock}. Сейчас так:
>> ls -l /var
>> .....
>> lrwxrwxrwx 1 root root 9 ноя 13 11:53 lock -> /run/lock
>> lrwxrwxrwx 1 root root 4 ноя 13 11:52 run -> /run
>>
>> Из использовавших файлы в /var/run оказались fail2ban, monit,
>> zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть
>> каталоги, которых нет в /run/lock. То же с /var/run и /run.
>> Мучает вопрос - после перезагрузки эти каталоги с нужными правами
>> будут созданы заново? Или это мусор, оставшийся в процессе обновлений
>> системы? Пока перезагрузиться и проверить не могу...
>
> В /run будут созданы каталоги, которые прописаны в конфигах:
>
> /lib/tmpfiles.d/*.conf
>
> /etc/tmpfiles.d/*.conf
>
> Если какие-то пакеты всё ещё напрямую содержат каталоги в /var/run и
> не имеют конфигов tmpfiles.d, то на них нужно заводить баги и срочно
> исправлять.
Попробовал провести процедуру на другой машине (libvirt там правда нет).
Поймал две проблемы:
1. Не стартует amavisd из-за неправильных прав на каталог
/var/run/amavis - выставлены 755, нужны 775. Ошибка в файле
/lib/tmpfiles.d/amavisd.conf.
2. При старте nginx ругается на невозможность создать
/var/lock/nginx/nginx. Этот каталог файлах tmpfiles.d не указан, но
прописан как LOCKFILE в init-скрипте nginx. Тут склоняюсь к тому. что
неправ init-скрипт и lock-файл нужно создавать в стандартном месте -
/var/lock/subsys.
Стоит вешать баги на amavisd-new и nginx по этому поводу (sysvinit
все-таки...)?
14.11.2019 21:37, Alex Moskalenko пишет: > Антон Мидюков писал 13.11.2019 13:32: >> 13.11.2019 16:53, Alex Moskalenko пишет: >>> Антон Мидюков писал 13.11.2019 11:33: >>>>> Я правильно понимаю, что нужно переместить текущее содержимое >>>>> /var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и >>>>> создать симлинки /var/run->/run и /var/lock->/run/lock? >>>>> >>>> Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже >>>> установленные системы пользователи должны переводить сами, при >>>> необходимости. >>> Переместил содержимое и сделал симлинки, предварительно остановив и >>> запустив после создания симлинков тех, кто использовал >>> /var/{run/lock}. Сейчас так: >>> ls -l /var >>> ..... >>> lrwxrwxrwx 1 root root 9 ноя 13 11:53 lock -> /run/lock >>> lrwxrwxrwx 1 root root 4 ноя 13 11:52 run -> /run >>> >>> Из использовавших файлы в /var/run оказались fail2ban, monit, >>> zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть >>> каталоги, которых нет в /run/lock. То же с /var/run и /run. >>> Мучает вопрос - после перезагрузки эти каталоги с нужными правами >>> будут созданы заново? Или это мусор, оставшийся в процессе >>> обновлений системы? Пока перезагрузиться и проверить не могу... >> >> В /run будут созданы каталоги, которые прописаны в конфигах: >> >> /lib/tmpfiles.d/*.conf >> >> /etc/tmpfiles.d/*.conf >> >> Если какие-то пакеты всё ещё напрямую содержат каталоги в /var/run и >> не имеют конфигов tmpfiles.d, то на них нужно заводить баги и срочно >> исправлять. > Попробовал провести процедуру на другой машине (libvirt там правда > нет). Поймал две проблемы: > > 1. Не стартует amavisd из-за неправильных прав на каталог > /var/run/amavis - выставлены 755, нужны 775. Ошибка в файле > /lib/tmpfiles.d/amavisd.conf. > 2. При старте nginx ругается на невозможность создать > /var/lock/nginx/nginx. Этот каталог файлах tmpfiles.d не указан, но > прописан как LOCKFILE в init-скрипте nginx. Тут склоняюсь к тому. что > неправ init-скрипт и lock-файл нужно создавать в стандартном месте - > /var/lock/subsys. > > Стоит вешать баги на amavisd-new и nginx по этому поводу (sysvinit > все-таки...)? Конечно же стоит! > _______________________________________________ > Sysadmins mailing list > Sysadmins@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/sysadmins -- С уважением, Антон Мидюков <antohami@altlinux.org>
Антон Мидюков писал 14.11.2019 17:41:
> 14.11.2019 21:37, Alex Moskalenko пишет:
>> Попробовал провести процедуру на другой машине (libvirt там правда
>> нет). Поймал две проблемы:
>>
>> 1. Не стартует amavisd из-за неправильных прав на каталог
>> /var/run/amavis - выставлены 755, нужны 775. Ошибка в файле
>> /lib/tmpfiles.d/amavisd.conf.
>> 2. При старте nginx ругается на невозможность создать
>> /var/lock/nginx/nginx. Этот каталог файлах tmpfiles.d не указан, но
>> прописан как LOCKFILE в init-скрипте nginx. Тут склоняюсь к тому. что
>> неправ init-скрипт и lock-файл нужно создавать в стандартном месте -
>> /var/lock/subsys.
>>
>> Стоит вешать баги на amavisd-new и nginx по этому поводу (sysvinit
>> все-таки...)?
> Конечно же стоит!
#37488 для amavisd-new, #37489 для nginx.
---
WBR, Alex Moskalenko
Здравствуйте. Наткнулся еще на две проблемы после переезда /var/run->run на sysvinit. 1. Каталог /var/run/devecot присутствует в пакете dovecot, файл для tmpfiles.d отсутствует. #37554. 2. sqlgrey не может работать со своим pid-файлом в /var/run. Предлагаю перенести его в /var/run/sqlgrey с соответствующими правками /etc/sqlgrey/sqlgrey.conf, /etc/init.d/sqlgrey и созданием файла для tmpfiles.d. #37555.
Hi Alex!
On 11/28/2019, at 12:45:14 PM you wrote:
> Здравствуйте.
>
> Наткнулся еще на две проблемы после переезда /var/run->run на sysvinit.
>
> 1. Каталог /var/run/devecot присутствует в пакете dovecot, файл для
> tmpfiles.d отсутствует. #37554.
> 2. sqlgrey не может работать со своим pid-файлом в /var/run. Предлагаю
> перенести его в /var/run/sqlgrey с соответствующими правками
> /etc/sqlgrey/sqlgrey.conf, /etc/init.d/sqlgrey и созданием файла для
> tmpfiles.d. #37555.
sqlgrey я думаю можно вообще закопать уже. Есть другие альтернативы,
которые работают быстрее и еще поддерживаются. Сам уже перешел с него на
milter-greylist и не жалуюсь )
--
WBR et al.
On Monday 02 December 2019, Konstantin Lepikhov wrote:
> Сам уже перешел с него на milter-greylist и не жалуюсь )
А он, в правильный момент грейлистрит, или в момент mail from?
--
С уважением, Сергей.
Hi Sergey! On 12/06/2019, at 06:37:25 PM you wrote: > On Monday 02 December 2019, Konstantin Lepikhov wrote: > > > Сам уже перешел с него на milter-greylist и не жалуюсь ) > > А он, в правильный момент грейлистрит, или в момент mail from? Ну если sendmail то там как макросы настроишь: http://milter-greylist.wikidot.com/sendmail -- WBR et al.