нагрузка процессора при проверке обновлений ...

вот удивлялся я почему новельный ультрабук то почти 6 часов работает на одной “заправке” вещая и-нет трансляцией,то и двух не вытягивает находясь вовсе в покое,но включенный…сегодня обратил внимание что греется слишком…запустил HTOP и наблюдал такую картину кряду часа полтора,пока батарея таки не села… два ядра из четырёх с максимальной нагрузкой (от 98% до 100%) на максимальной частоте трудились отрабатывая всего два процесса,при этом все остальные процессы с системе и 3 %не грузили оставшиеся ядра…
самый прожорливый висел этот /usr/bin/phyton 2.7/ cl-update --schedule -p --wait-anoter-update off
второй ему на помощь этот /usr/bin/emerge -av --color=y --nospinner -uDN -pv --with-bdeps=y @world
и трудились они над прогревом бука и воздуха больше полутора часов кряду,так и не вытянув с зеркал даже признаков обновки…
так понимаю что это автоматическая проверка обновлений системы и что такое поведение не есть норма,тем более так происходит всё же не постоянно,но происходит,если судить по времени жизни бука на одной зарядке…попробовал прибить и один и второй,но спустя несколько минут они возобновились,это видимо крон уже их поднял по времени…хотелось бы уточнить как работает механизм обновления…на обеих сторонах и зеркалах оверлеев и на десктопе,есть ли где почитать как реализовали данный механизм,и его алгоритмы?

P.S.хочется понять где у меня в системе может происходить сбой и проверка не завершается как по логике вещей должно былобы быть…потому как на старой машинке в 14 альфе такого не было,время работы от акб не гуляло таким непредсказуемым образом…

Присоединяюсь к вопросу…
Тоже напрягает такое поведение, когда сидишь спокойно работаешь и начинаются дикие тормоза.
У себя пока отключил это действо в /etc/cron.d/calculate-update

Что выдает?

@/usr/bin/emerge -av --color=y --nospinner -uDN -pv --with-bdeps=y world
calculate ersch13 # /usr/bin/emerge -av --color=y --nospinner -uDN -pv --with-bdeps=y @world 

Local copy of remote index is up-to-date and will be used.

These are the packages that would be merged, in order:

Calculating dependencies  ... ... . ..... done!

Total: 0 packages, Size of downloads: 0 kB

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

А можно увидеть содержимое файла? (файл можно передать через форум)

/var/log/calculate/core-action.log

у меня два таких файла core-action.log и core-action.log.1…при чём тот что с расширением 1 обрывается строчкой старт апдэйт а тот который просил показать начинается по времени с обрыва первого,но и нагрев бука пошёл примерно тогдаже,я заметил через пару часов что с буком не то…не уверен конечно,но сдаётся что всё это взаимосвязано с необычным поведением системы…файлы я конечно выложу,только такой обьём однообразных записей…у меня в глазах зарябило когда только просмотрел не вникая в сообщения… )))

core-action.log.1 (1020 KB)
core-action.log (51.6 KB)

P.S. единственное что сразу бросилось в глаза это смена времени проверки причём новое время похоже назначилось когда и произошёл сбой,сделал такой вывод исходя из того,что проверка пошла дважды в течение одного часа,и точно знаю что на тот период времени бука никто не касался,он просто стоял включенный с открытым чертежом в пдф-е на экране…

Вызов cl-update удален из /etc/crontab ?

Aleksey Mikhaleff wrote:

P.S. единственное что сразу бросилось в глаза это смена времени проверки причём новое время похоже назначилось когда и произошёл сбой

А в каком из логов и каком участке это видно?

Запуск утилиты именно на проверку я вижу в 7 сентябра в 1:17 и 13:17. Остальное проверки о необходимости запуска.

Mikhail Hiretsky wrote:

Вызов cl-update удален из /etc/crontab ?

нет

Mikhail Hiretsky wrote:

Запуск утилиты именно на проверку я вижу в 7 сентябра в 1:17 и 13:17. Остальное проверки о необходимости запуска.

в логе .1 время другое, 10 минут каждого часа,пролистал оба лога больше нигде время не сменяется а смена в самом начале продолжения лога…и ,Миш,речь и идёт о проверках,при собственно обновлении камень больше 30-40% не грузится и явных тормозов нет,сегодня утром обновки шли всё нормально прошло,даже сталкер не подвисает…а во время глюка только курсор мышом волохается,HTOP запускался несколько минут…

Aleksey Mikhaleff wrote:

Mikhail Hiretsky wrote:

Вызов cl-update удален из /etc/crontab ?

нет

То есть он и в /etc/cron.d и в /etc/crontab ?

как должно быть в дефолте,я ничего не менял в кроне как ставил из образа 13.19 от 12.07.2014 так и есть…сейчас гляну…

ага,вот их содержимое…

crontab (608 Bytes)
calculate-update (200 Bytes)

сегодняшнее обновление пакетов калько-утилит и калько инсталлера вернуло тормоза и пожирание батареи,после выполнения проверки не завершается процесс
python2 /usr/sbin/cl-update --shedule -p --wait -another-update off
при этом его ещё и прибить вручную стало не возможно,он тутже возобновляется и греет камень на всю катушку,одно ядро на 100% и периодически остальные три до 98% подхватываются,помогает только перезагрузка…запуск htop-а занимает от минуты до трёх,хромиум вообще 10 минут заводился,так сильно до этого не тормозило ни разу,хотя трабла вылезает регулярно на что каждый раз пытаюсь обратить ваше внимание,вроде устраняете и пару-тройку обновок проходят без сюрпризов потом опять… начало даже приносить большое неудобство очень быстро сажая батарею,пришлось специально вынести в панель мониторинг процессора чтобы вовремя заметить “несанкционированную” нагрузку…перезагружаться раз в час…ну весьма неудобственно…

55.png

А при вызове вручную

python2 /usr/sbin/cl-update --shedule -p --wait -another-update off

Что происходит?

также стартует и не убивается,пришлось перезагружать,кстати только что ещё обновки пришли(вторые за день,и вышеназванные пакеты присутствуют… буду посмотреть как будет себя вести система…

А на чём висит?

только что ещё обновки пришли

calculate-update уже давно не менялся

в смысле висит?в том то и дело что отработка при наличии обновлений происходит как положено,всё отрабатывается и закрывается,а вот если проверка обнаруживает отсутствие обновлений ,вот тут и начинается…причём похоже только если автоматом проверка стартует,если из калькоконсоли апдэйт или из терминала cl-update руками делать отрабатывает и закрывается,а во старт по крону судя по всему и подвешивает тот процесс…а вот почему перезапускается сам сразу после kill,это вопрос…