LINUX.ORG.RU

Ubuntu 20.04.1 LTS + acronis data protection 12.5

 , ,


0

1

Всем привет. Имеется vm с ubuntu 20.04.1 LTS, на которой монопольно развёрнут acronis data protection 12.5 (16215 сборка) и получилось что он сейчас вот такой выхлоп в лог делает.

acronis systemd[1]: acronis_monitoring_service.service: Succeeded.
acronis systemd[1]: acronis_monitoring_service.service: Scheduled restart job, restart counter is at 1643.
acronis systemd[1]: Stopped Acronis Monitoring Server Service.
acronis systemd[1]: Starting Acronis Monitoring Server Service...
acronis systemd[1]: Started Acronis Monitoring Server Service.
acronis acronis_monitoring_service[51522]: sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='stderr.log' mode='w' encoding='UTF-8'>
acronis acronis_monitoring_service[51522]: sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/var/lib/Acronis/MonitoringServer/Logs/monsvc-708820.output' mode='wt' encoding='utf-8-sig'>
acronis acronis_monitoring_service[51522]: Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fd2e33e1400>
acronis acronis_monitoring_service[51522]: Traceback (most recent call last):
acronis acronis_monitoring_service[51522]:   File "/usr/lib/Acronis/PyShell/stdlib.zip/weakref.py", line 117, in remove
acronis acronis_monitoring_service[51522]: TypeError: 'NoneType' object is not callable
acronis acronis_monitoring_service[51522]: Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fd2e33e1400>
acronis acronis_monitoring_service[51522]: Traceback (most recent call last):
acronis acronis_monitoring_service[51522]:   File "/usr/lib/Acronis/PyShell/stdlib.zip/weakref.py", line 117, in remove
acronis acronis_monitoring_service[51522]: TypeError: 'NoneType' object is not callable
acronis systemd[1]: acronis_monitoring_service.service: Succeeded.

Гугл ведёт на страницы вендора, где рекомендация проверки порта и рестарта службы, а потом в тех.поддержку сообщать.

Тех.поддержка предложила поднять релиз с 16215 до 16225.

Читаю в данный момент документацию, но может сможете подсказать куда точнее копать? Что бы понять - от чего это произошло.

Просто weakref.py - вроде как создаёт «слабые» ссылки, например для кэшей и потому, уже кончились идеи что проверить ещё.

Без исходников разобраться обычно невозможно, но здесь они вроде как есть.

weakref также часто используется, если в коде на Python используются деструкторы (это очень редко, но встречается), чтобы GC мог собрать циклические ссылки.

Здесь ткну пальцем в небо, и предположу, что для предотвращения утечки памяти или чего-то такого использовали weakref, и в момент завершения работы, когда деструктор чего-то пытается вызвать метод объекта по слабой ссылке, этот объект или метод уже были удалены GC, потому что не возникло цикла, или были явно разорваны циклические связи. Слабая ссылка стала недействительной, вот и исключение.

По-моему, даже в доке weakref написано, что перед вызовом методов/функций по слабым ссылкам, надо сначала проверять, что они ещё валидны.

emorozov
()
Ответ на: комментарий от emorozov

ткну пальцем в небо

И видимо вы попали, потому что оказывается что висит «мёртвый» процесс создания копии гипервизора одного.

Спасибо, натолкнули на мысли.

lawliet
() автор топика