Пропадают процессы, не закончившись

Oom killer

Он в dmesg появляется.

Oom killer

«краткость - сестра таланта», но, кроме сисадминов есть на свете и простые юзеры. Нельзя ли снизойти до них с Олимпа и привести команду как проверить это предположение? Спасибо

после 10ти часов счета отвалилась одна задача, как будто, ее убили kill’ом,

Я бы начал таки в выяснения вопроса «Как будто» или таки убили? Каким сигналом? Ты код выхода своей задачи смотрел? Вангую, что нет.

P.S.dmesg

dmesg показывает kernel ring buffer. Твоя задача — обычная приложуха. Если с ней что-то и случилось, то следы этого искать надо в journalctl, а не в dmesg.

Out Of Memory Killer – сервис, который при недостатке ОЗУ в системе прибивает некоторые процессы дабы эту самую память освободить.

Просмотрел историю на терминале, с которого была запущена задача - есть сообщение о старте процесса, но нет ничего о его окончании.
А команду с параметрами, как использовать journalctl западло было написать? Ох и вредный народишко, эти сисадмины. Задача выполняется из-под toolbox, система не видит бинарника, а из того контейнера я давно уже вышел, это новый вход:

xxx@toolbox:macro$ journalctl /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe --since yesterday
Hint: You are currently not seeing messages from other users and the system.
      Users in groups '4294967295', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --
xxx@toolbox:macro$ sudo journalctl /run/host/var/cvmfs/nica.jinr.ru/sw/slc7_x86-64/ROOT/v6.26.10-1/bin/root.exe --since yesterday

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

-- No entries --

Я какие-либо концы от того процесса найти не умею

Out Of Memory Killer

вопрос был не о том, что это, а КАК проверить предположение о том, что это ответственно за происшедшее

Обнаружил, что чехарда с памятью появилась сразу после команды

sudo fstrim /home

Просмотрел историю на терминале, с которого была запущена задача - есть сообщение о старте процесса, но нет ничего о его окончании.

А должно быть?

Ты сам запускал процесс — так модифицируй его запуск и визуализируй его завершение. Сделать это тривиально:

$ your-task; echo "Process exit status: $?"

После этого не надо будет гадать что случилось с процессом.

А команду с параметрами, как использовать journalctl западло было написать? Ох и вредный народишко, эти сисадмины.

Во-первых, я не сисадмин. Во-вторых, набрать команду man journalctl тебе западло было? В-третьих, уровень гонора в твоих сообщениях зашкаливает. Либо засунь свой гонор куда-нибудь, либо сам иди туда же.

А должно быть?

Конечно должно ! Практически у всех же есть что-то вроде этого

~ ∫ function fish_prompt                                                                      
            echo -n (fish_status_to_signal $pipestatus | string join '|') (prompt_pwd) '$ '
    end

0 ~ $
0 ~ $ false
1 ~ $ true
0 ~ $ sleep 100                                                                               
^C⏎
SIGINT ~ $

Или еще нет ? 😀

nohup «task» &
начинается с сообщения о старте процесса с указанием его номера, а заканчивается тоже сообщением.

«man journalctl» выдает более 30ти страниц, и многие из параметров - просто темный лес. У меня нет столько «гонора» как у Вас, любезнейший, потому что я не претендую на то, что сразу разберусь в любом manuale, неизвестно каким специалистом и носителем какого языка написанным.

Я с Вами «на брудершафт» (по немецки «дружба») не пил. Тыканье незнакомым и старшим есть удел плохо воспитанных людей с обостренным чувством собственной неполноценности.

искать надо в journalctl

Там с вероятностью 99% навалена куча мусора и нет ничего полезного. Это если вы сможете выбить из него данные.

Я уверен - journalctl абсолютно бесполезен если приложение само к нему не обратилось и не положило в него логи (что плохо работает, если оно упало или было кем то убито). Первые предположения: oom-киллер и глянуть что оно само в терминал написало - самые разумные.

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

По поводу oomd - не знаю есть ли он в убунту 22.04, если да то какой и как смотреть его сработки. Но вот гугл и яндекс за пару (десятков) минут ответят на эти вопросы. И зная куда копать вы найдёте ответ быстрее чем дождётесь его здесь.

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

sudo fstrim /home

Серьёзно? точно? А если попробовать повторить? Хрен знает, может у приложения какая нибудь аллергия на задержки по диску, но без вывода ошибки i/o в терминал.

Во-первых, почему .exe? Что-то на моно? Во-вторых, я вижу у процесса с PID 3925 43,6% потребления оперативки, выглядит как то что твоя программа течёт и приходит OOM killer.

Я тоже это вижу, но не вижу этому причины. 6 часов (!) все эти процессы работали аналогично потребляя память и СPU. Различие появилось CРАЗУ после

fstrim /home

Этот процесс я запустил утром на другом компе, и он уже отработал более 7 часов без подобных приключений. Хочется осознать разумом, что произошло - кроме fstrim грешить не на что. Я упоминал, что на этом компе и раньше случалось что-то подобное, и я точно грешил тогда тоже этой командой без особой нужды. SSD на этом компе 5ти летнего возраста и невзрачной марки SmartBuy, но у s.m.a.r.t к нему нет претензий, да и эту команду я выдал вчера так, без надобности, просто для «успокоения», веря, что вреда-то она нанести не может…

journalctl -xb --no-pager | grep Killed

У меня показывает, что было убито OOM с последней перезагрузки. Ну или без грепа искать глазами, как вариант.

Вероятно процессы забрали всю память и когда ты запустил fstrim, который тоже захотел памяти, OOMKiller пришел и начал убивать кого попало.

он уже отработал более 7 часов без подобных приключений. Хочется осознать разумом, что произошло - кроме fstrim грешить не на что.

Да вот хз. oomd штука очень непредсказуемая, возможно её спровоцировала какая агресивная операция над дисковымикешами, вызванная fstrim. Ну или сбой i/o в самой программе из за подвисаний диска.

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

В одной из прошлых тем у вас на корне (/) было 5% свободного места: Прерывистая работа системы (комментарий)

проверьте на этой системе тоже (df -hT).

И, потом, fstrim руками не нужно запускать, на Ubuntu он автоматически выполняется раз в неделю.

nica.jinr.ru

Ты из оияи? Когда нику запустите?

Когда нику запустите?

Это не ко мне, к ускорителю отношения не имею, но могу сказать, что из-за санкций «железо» до конца доделать пока не могут.

Спасибо за внимание, да, как раз на этом компе тот самый диск с того компа, но на нем системе я подкинул 20 гигов. Насчет «автомата» не знаю, но поверить могу.

Я с Вами «на брудершафт» (по немецки «дружба») не пил. Тыканье незнакомым и старшим есть удел плохо воспитанных людей с обостренным чувством собственной неполноценности.

Гм, человек, начавший с предъяв на уголовном арго («западло было написать?»), укоряет меня в невоспитанности из-за обращения «ты»? Смешно. Шути дальше.

Память проверь

Думаю, «это вряд ли», но когда все досчитается то для «чистоты эксперимента» обязательно проверю. Вот только вопрос неясный - сколько эту проверку гонять?

штука очень непредсказуемая

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

попробовал
journalctl -xb –no-pager | grep Kill
то, что попало в журнал, к делу отношения не имеет.

Задача выполняется из-под toolbox, система не видит бинарника, а из того контейнера я давно уже вышел, это новый вход

Если процессы эти запускаются каким-то ПО в контейнерах вроде Docker, а не напрямую в системе, то и искать записи о падении процесса внутри контейнера стоит в логах системы контейнеризации. Так как когда ПО падает, вероятно, контейнер своё выполнение тоже прерывает.

И да, процесс может быть прибит не только в рамках OOM, поэтому логи стоит проверять и на другие причины падения процессов. Плюс, трабла может быть с битой памятью, к примеру.

Я бы, на вашем месте, попытался настроить coredump для падающих процессов, и более подробное логирование системных ошибок. Но, если ПО запускают в контейнерах, сами вы, вероятно это дело не осилите. Стоит пнуть админа, что отвечает у вас за IT в вашем заведении, чтобы он изменил Docker-файлы для тасков, добавив туда выгрузку coredump и подробное логирование. Нужен профильный специалист, так как анализировать состояние процесса перед падением с помощью coredump и того же gnudebug, вы, вероятно сами всё равно не сможете. Да и в устройстве вашего toolbox, как я понимаю, не сильно разбираетесь. Попытки решить траблу самостоятельно в таком случае будут контрпродуктивны. Если вы нацелены на результат, конечно, а не просто поковыряться.

Вы написали все правильно, но как еще когда-то сказал В.И.Ленин «страшно далеки от народа», потому что я пользуюсь чем-то «государственным», но требовать у меня нет полномочий. Да и при дефиците системщиков с больщой буквы, не сисадминов, однако, это нереально. Я использую ЛИЧНЫЕ компьютеры не от далеко хорошей обстановки с наукой в РФ, но удается даже публиковать статьи у «них».

Моя более чем 50ти летняя практика программирования подсказывает, что в данном случае я наткнулся на не состыкованность отдельных компонентов вычислений ОС linux, рад ошибиться, но «истина дороже», тем более, что «мои» системщики, попытавшие сделать в рамках проекта «универсальный» линукс к Убунте относятся с большой прохладцей, считая Федору более настоящим линухом.

В мире всё и всегда детерминировано, но всё таки существуют такие хаотичные процессы...

Где то там есть cgrops в которой по умолчанию применяются некие лимиты памяти (я лично наталкивался на дебиан-8 с совершенно невменяемым вариантом, с тех пор глушу подсистему ещё на подлёте), где то есть настройки вытеснения страниц приложений, страниц кешей и ещё каких то страниц, связанных с библиотеками (крайне смутно понимаю смысл механизма, но вроде как есть большая разница в разных сценариях нехватки памяти). И ещё у ядра бывают трудности с экстренным высвобождением памяти из под дисковых кешей, а trim вполне может попросить весь мир подождать. Плюс возможно существование автоматического поднятия zram (а он не всегда работает в плюс, иногда можно и нарваться), автоматического создания своп-файла в случае нехватки (хотя на это мода вроде бы ушла, но именно в убунту я такое выдел) и монтирование /tmp (и не только) в tmpfs. И вот это вот всё может дать очень интересную ситуацию если одновременно в 2-3 подсистемах произойдёт что то нестандартное и жирное.

О, точно. И это тоже.

считая Федору более настоящим линухом

Федора давно перестала быть юниксом вообще, к тому же все самые странные и дикие эксперименты идут оттуда.

У человека 50 лет опыта в программировании. Он может себе позволить и coredump, и strace, и даже gdb. Чего мы мучаемся-то.

Поговорку напомню: в чужой монастырь со своим уставом не ходят.

1.Предъявите свои права на «монастырь».
2.Существуют в русском обществе общепринятые правила общения между людьми. Если Вы их отрицаете, то Ваш «монастырь» превращается в секту

Память проверил. Как и предполагал, с ней все в порядке.

Если ты немедленно не прекратишь общение в таком ключе, дальше оно тут будет затруднено.

1.Если я Вас лично чем-то оскорбил или нарушил правила общения на этом форуме, предъявите конкретные претензии. 2.Вы против вежливого общения?

Разница только в начальном случайном числе.

Возьми числа с компов на которых всё закончилось хорошо и стартани на падучем. И наоборот.

Может тебе просто повезло и генератор нагенерил плохие входные данные.

генератор нагенерил плохие входные данные

это исключено, поверьте на слово. «Упавшая» задача с теми же числами досчитывается до конца на любом компьютере.
Думаю, что через пару-тройку дней смогу доказать, что это fstrim «гадит». Еще практически разгадана тайна случайного зависания Ryzen, но для окончательного вывода также нужно еще несколько дней для проверки.

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

это исключено

Я уже много раз встречал эти "исключено". Ты бы проверил всё таки.

Ты бы проверил всё таки.

А какие у Вас основания не верить именно мне? Потому что лично для Вас я не стал приводить доказательства того, что в этот раз Вы не угадали? Разрешите спросить - Вы всем людям на 8м десятке тыкаете?

Основания для заявлений, что всё работает и возраст я, очевидно, должен был... угадать?

считая Федору более настоящим линухом

посмеялся в голос, спасибо

А команду с параметрами, как использовать journalctl западло было написать? Ох и вредный народишко, эти сисадмины.

Параметры мало кто наизусть помнит, так что придется самому искать.

«man journalctl» выдает более 30ти страниц

Меньше неадеквата, а? Вам нужно всего лишь посмотреть сообщения из журнала.

Вы всем людям на 8м десятке тыкаете?

Вы просто не знакомы с сетевым этикетом, общаться на «ты» на подобных форумах - норма.

Всё-таки больше похоже на битый модуль ОЗУ, который, с современных условиях, отловить будет очень трудно. Слишком много мозгов у компонентов.

А почему у вас машины без ECC? Я, например, простой админ, не могу себе позволить иметь рабочую машину без ECC. А у вас там расчёты. Странно это. Платформы на базе AMD позволяют строить с использованием ECC.

Это не память, я сегодня пол-дня гонял memtest86, но, скорее, для «чистоты эксперимента».

Мне удобнее по некоторым причинам использовать свои компьютеры, вычислительные фермы заточены под определенный, другой класс задач. Наука в РФ занимает одно из последних мест. Более-менее существуют те ученые, кто работает в международных коллаборациях, проводя большую часть времени в загранкомандировках. Мне чужбина уже надоела за последние 30 лет. Так что, все упирается в финансы.

Вы просто не знакомы с сетевым этикетом

У меня интернет появился дома в 90х тогда, когда он только появился в РФ. Для воспитанного интеллигентного человека никогда «нормой» не может быть тыканье старшим и незнакомым людям. Не забывайте, что за каждым ником живой человек а не придуманный Грефом для нашего президента ИИ.

memtest86

оно давно толком не работает, говорю же. Слишком много мозгов что в модулях, что в контроллерах.

Так что, все упирается в финансы.

ECC поддерживается множеством «обычных» систем, практически без переплаты. У меня система на AM3+ лежит с фуфиксом и 16 гигами ECC.