Стек памяти ошибок сегментации сброшен на диск

Обновлено: 21.11.2024

SIGSEGV, также известный как нарушение сегментации или ошибка сегментации, представляет собой сигнал, используемый операционными системами на базе Unix (например, Linux). Это указывает на попытку программы выполнить запись или чтение за пределы выделенной памяти — либо из-за ошибки программирования, проблемы совместимости программного или аппаратного обеспечения, либо из-за злоумышленной атаки, такой как переполнение буфера.

SIGSEGV обозначается следующими кодами:

  • В Unix/Linux SIGSEGV – это сигнал операционной системы 11.
  • В контейнерах Docker, когда контейнер Docker завершает работу из-за ошибки SIGSEV, выдается код выхода 139.

Действием по умолчанию для SIGSEGV является аварийное завершение процесса. Кроме того, может иметь место следующее:

  • Основной файл обычно создается для обеспечения возможности отладки.
  • Сигналы SIGSEGV могут регистрироваться более подробно для устранения неполадок и в целях безопасности.
  • Операционная система может выполнять операции, зависящие от платформы.
  • Операционная система может разрешить самому процессу обрабатывать нарушение сегментации.

SIGSEGV — частая причина завершения работы контейнера в Kubernetes. Однако Kubernetes не запускает SIGSEGV напрямую. Чтобы решить эту проблему, вам потребуется отладить проблемный контейнер или базовый хост.

SIGSEGV (код выхода 139) и SIGABRT (код выхода 134)

SIGSEGV и SIGABRT — это два сигнала Unix, которые могут привести к завершению процесса.

SIGSEGV запускается операционной системой, которая обнаруживает, что процесс выполняет нарушение памяти, и может в результате завершить его.

SIGABRT (сигнал прерывания) — это сигнал, запускаемый самим процессом. Аварийно завершает процесс, закрывает и сбрасывает открытые потоки. После запуска процесс не может заблокировать его (аналогично SIGKILL, но отличается тем, что SIGKILL запускается операционной системой).

Перед отправкой сигнала SIGABRT процесс может:

  • Вызовите функцию abort() в библиотеке libc, которая разблокирует сигнал SIGABRT. Затем процесс может прерваться, инициировав SIGABRT
  • Вызывает макрос assert(), который используется при отладке, и прерывает программу с помощью SIGABRT, если утверждение ложно.

Коды выхода 139 и 134 параллельны SIGSEGV и SIGABRT в контейнерах Docker:

  • Код выхода Docker 139 – означает, что контейнер получил сигнал SIGSEGV от базовой операционной системы из-за нарушения памяти.
  • Код выхода Docker 134 – означает, что контейнер активировал сигнал SIGABRT и был аварийно завершен.

Попробуйте Комодор!

Получите контекст, необходимый для эффективного и независимого устранения неполадок

Что вызывает SIGSEGV?

Современные вычислительные системы общего назначения включают блоки управления памятью (MMU). MMU обеспечивает защиту памяти в таких операционных системах, как Linux, не позволяя различным процессам получать доступ или изменять память друг друга, кроме как через строго контролируемый API. Это упрощает устранение неполадок и делает процессы более отказоустойчивыми, поскольку они тщательно изолированы друг от друга.

Сигнал SIGSEGV или ошибка сегментации возникает, когда процесс пытается использовать адрес памяти, не назначенный ему MMU. Это может произойти по трем распространенным причинам:

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

Обработка ошибок SIGSEGV

В операционной системе на основе Unix сигнал SIGSEGV по умолчанию приводит к аварийному завершению процесса, нарушающего правила.

Дополнительные действия, выполняемые операционной системой

Помимо завершения процесса, операционная система может создавать файлы ядра для облегчения отладки, а также может выполнять другие операции, зависящие от платформы.Например,
в Linux можно использовать утилиту grsecurity для подробного ведения журнала сигналов SIGSEGV, чтобы отслеживать связанные угрозы безопасности, такие как переполнение буфера.

Разрешение процессу обрабатывать SIGSEGV

В Linux и Windows операционная система позволяет процессам обрабатывать свои ответы на нарушения сегментации. Например, программа может собрать трассировку стека с такой информацией, как значения регистров процессора и адреса памяти, которые были связаны с ошибкой сегментации.

Примером этого является segvcatch, библиотека C++, которая поддерживает несколько операционных систем и способна преобразовывать ошибки сегментации и другие исключения, связанные с оборудованием, в исключения программного языка. Это позволяет обрабатывать «серьезные» ошибки, такие как нарушения сегментации, с помощью простого кода try/catch. Это позволяет программному обеспечению идентифицировать нарушение сегментации и исправить его во время выполнения программы.

Устранение неполадок SIGSEGV

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

Устранение распространенных ошибок сегментации в Kubernetes

Ошибки SIGSEGV очень важны для пользователей и администраторов Kubernetes. Довольно часто контейнер выходит из строя из-за нарушения сегментации.

Однако, в отличие от других сигналов, таких как SIGTERM и SIGKILL, Kubernetes не запускает сигнал SIGSEGV напрямую. Вместо этого хост-компьютер на узле Kubernetes может инициировать SIGSEGV, когда контейнер обнаруживает нарушение памяти. Затем контейнер завершает работу, Kubernetes обнаруживает это и может попытаться перезапустить его в зависимости от конфигурации модуля.

Когда контейнер Docker завершается сигналом SIGSEGV, он выдает код выхода 139. Это может означать:

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

Чтобы отладить и устранить проблему SIGSEGV в контейнере, выполните следующие действия:

  1. Получите root-доступ к хост-компьютеру и просмотрите журналы, чтобы увидеть дополнительную информацию об ошибочном контейнере. В журналах kubelet ошибка SIGSEGV выглядит следующим образом:
  2. Попытайтесь определить, на каком уровне образа контейнера возникает ошибка — она может быть в коде вашего конкретного приложения или ниже в базовом образе контейнера.
  3. Запустите docker pull [image-id], чтобы получить образ для контейнера, завершенного SIGSEGV.
  4. Убедитесь, что у вас установлены инструменты отладки (например, curl или vim), или добавьте их.
  5. Используйте kubectl для выполнения в контейнере. Посмотрите, сможете ли вы воспроизвести ошибку SIGSEGV, чтобы подтвердить, какая библиотека вызывает проблему.
  6. Если вы определили библиотеку или библиотеки, вызывающие нарушение памяти, попробуйте изменить изображение, чтобы исправить библиотеку, вызывающую нарушение памяти, или заменить ее другой библиотекой. Очень часто проблема решается обновлением библиотеки до более новой версии или до версии, совместимой со средой на хосте.
  7. Если вы не можете определить библиотеку, которая постоянно вызывает ошибку, возможно, проблема связана с хостом. Проверьте наличие проблем с конфигурацией памяти хоста или оборудованием памяти.

Описанный выше процесс может помочь вам устранить простые ошибки SIGSEGV, но во многих случаях устранение неполадок может стать очень сложным и потребовать нелинейного исследования с участием нескольких компонентов. Именно поэтому мы создали Komodor — для устранения ошибок памяти и других сложных проблем Kubernetes до того, как они выйдут из-под контроля.

Устранение неполадок с завершением работы контейнера Kubernetes с помощью Komodor

Для администратора или пользователя Kubernetes неожиданное завершение работы модулей или контейнеров может стать проблемой и привести к серьезным производственным проблемам. Завершение контейнера может быть результатом множества проблем в разных компонентах, и его может быть трудно диагностировать. Процесс устранения неполадок в Kubernetes сложен и без правильных инструментов может быть напряженным, неэффективным и трудоемким.

Некоторые передовые практики могут помочь свести к минимуму вероятность того, что сигналы SIGSEGV или SIGABRT повлияют на ваши приложения, но в конечном итоге что-то пойдет не так — просто потому, что это возможно.

Вот почему мы создали Komodor, инструмент, который помогает командам разработчиков и операторов перестать тратить свое драгоценное время на поиски иголок в стогах (сена) каждый раз, когда что-то идет не так.

Выступая в качестве единого источника достоверной информации (SSOT) для всех ваших потребностей в устранении неполадок k8s, Komodor предлагает:

  • Информация об изменениях. Каждая проблема возникает в результате изменений. За считанные секунды мы сможем помочь вам понять, кто, что и когда сделал.
  • Подробный обзор: полная хронология действий, показывающая все изменения кода и конфигурации, развертывания, оповещения, различия кода, журналы модулей и т. д. Все в одной панели с удобными параметрами детализации.
  • Понимание зависимостей служб. Простой способ понять межсервисные изменения и визуализировать их влияние на всю систему.
  • Бесшовные уведомления. Прямая интеграция с вашими существующими каналами связи (например, Slack), чтобы у вас была вся необходимая информация, когда она вам нужна.

Если вы хотите попробовать Komodor, используйте эту ссылку, чтобы подписаться на бесплатную пробную версию.

Обнаружение ошибки сегментации

По многочисленным просьбам я написал краткое руководство, чтобы помочь программистам отлаживать ошибки в этой обширной теме. Начнем с краткого введения.

Введение
Задаваясь вопросом об этих ошибках и о том, почему они возникают без предварительного предупреждения, программисты постоянно задают такие вопросы, как «Почему я получаю эту ошибку?» или «Что это за ошибка? ? На эти вопросы можно найти ответы.

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

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

Следующий список поможет вам лучше понять ошибку сегментации:

  • Ошибка сегментации может быть ошибкой, при которой запущенная программа пытается получить доступ к памяти, не выделенной ей, и создает дамп ядра с ошибкой нарушения сегментации.
  • Ошибка сегментации может быть вызвана неправильным использованием памяти. Ваша программа пытается выполнить ввод-вывод в области памяти, к которой ей не разрешен доступ. Это может иметь много причин; некоторые из наиболее распространенных — «дикие указатели» и переполнение буфера (например, выделение n символов для буфера и запись n+1 символов).
  • Ошибка сегментации (иногда для краткости называемая ошибкой сегментации) может представлять собой особое состояние ошибки, которое может возникнуть во время работы компьютерного программного обеспечения. Короче говоря, ошибка сегментации возникает, когда программа пытается получить доступ к ячейке памяти, к которой ей не разрешен доступ, или пытается получить доступ к ячейке памяти недопустимым способом (например, пытается записать ячейку, доступную только для чтения). ).
  • Ошибка сегментации может быть типом ошибки, возникающей при попытке доступа к несуществующему адресу физической памяти.
  • Ошибка сегментации может возникнуть, если вы освободили память, а затем в рамках той же программы попытаетесь повторно использовать ту же память.
  • Ошибка сегментации для программного обеспечения может возникнуть в случае аппаратных ошибок, например сбоя жесткого диска или памяти. Чтобы выяснить это, попробуйте запустить memtest86 и/или любые средства диагностики жесткого диска от производителя.
  • Ошибка сегментации может быть ошибкой, при которой запущенная программа пытается получить доступ к памяти, не выделенной ей, и создает дамп ядра с ошибкой нарушения сегментации. Это часто вызвано неправильным использованием указателей в исходном коде, разыменованием нулевого указателя или (в C) непреднамеренным использованием переменной без указателя в качестве указателя.
  • Ошибка сегментации может возникнуть при запуске программы, которая читает или записывает несуществующий сегмент (пространство физической памяти).
  • Это может быть спорадическим явлением.

Далее приведены некоторые примеры, которые вызывают ошибки сегментации или нарушения памяти.

Это вызывает нарушение, поскольку мы пытаемся изменить abc, который на данный момент содержит недопустимый адрес. Помните, abc — это указатель. Помните, указатель — это переменная, содержащая адрес другой переменной. Эта программа дает сбой, потому что мы пытаемся записать в чужую память. Как и обычные переменные, неинициализированные указатели не вызовут ошибки компиляции, но использование неинициализированных указателей может привести к непредсказуемым и потенциально катастрофическим результатам.

В других случаях используются строковые литералы и константы. Наш следующий пример покажет, что abc — это указатель, который инициализируется, чтобы содержать доступный только для чтения адрес строковой константы; указатель может быть впоследствии изменен, чтобы указывать в другом месте, но результат не определен, если вы попытаетесь изменить содержимое строки.

Однако эта программа не дает сбоев. Это приведет только к сбою, если мы попытаемся изменить содержимое строки. Это похоже на квалификатор const. Первое правило квалификатора const таково: константа должна быть инициализирована, ей нельзя присвоить значение где-либо еще.Имейте в виду, что компилятор не выдает предупреждения, если указатель небезопасен/не разрешено изменять его содержимое.

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

Мы знаем, что в C++ массив — это конкретная структура данных, которую можно использовать для реализации типа данных Array или Vector (хотя возможны и другие реализации).

  • Все элементы массива относятся к одному типу
  • Доступ к элементам осуществляется по их индексу, начиная с 0
  • Массив имеет фиксированную емкость, которая должна быть известна во время компиляции.

Индексы массива всегда начинаются с нуля в C, поэтому элементы abc[0], abc[1], �, abc[5]. Проще говоря, если подсчитать 6 чисел, начиная с 0, получится 5.

Переходя от простых примеров, давайте рассмотрим указатели на классы и указатели на структуры. Мы знаем, что пока указатель не содержит адрес переменной, он бесполезен. Как правило, указатели могут быть выделены с помощью new/delete в C++, malloc() и free() в C по адресу другого объекта или даже принимать литерал или постоянное значение/строку. Некоторые проблемы заключаются в том, что мы создаем указатель на класс и ожидаем, что он будет работать. Для структур/классов оператор �.� соединяет имя структуры/класса и имя члена. Указатели на структуры/классы, с другой стороны, используют альтернативную нотацию в качестве сокращения, используя оператор �->�. Оба этих оператора читаются слева направо. При работе с указателями на структуры/классы будет использоваться оператор �->�.

При компиляции и выполнении примера 1.4 произойдет ошибка сегментации. Указатель foo на Foo не содержит допустимого объекта или адреса, что приведет к сбою.

Указатели, прежде всего другие переменные, лучше других выражают вычисления и иногда являются единственным способом. Гибкость указателей может быть опасной. Память является ключевым моментом при запуске машины или программы. Изучение того, как обращаться с памятью на языке C/C++, имеет преимущество. Это руководство представляет собой руководство по изучению ошибок сегментации и причин их возникновения. Лучший способ исправить ошибку сегментации — научиться правильно обращаться с памятью, выделять и освобождать ее. В других руководствах часто задаваемых вопросов есть много руководств по выделению памяти, передаче памяти объектов и совместному использованию памяти.

Поиск ошибки
С другой стороны, обнаружение ошибки сегментации может быть затруднено, если вы это сделаете. Хороший инструмент — смотреть. Ищите любые указатели, которые могут быть неинициализированы, изменены как литералы или константы, разыменованы при значении NULL или обращаются к чужой памяти.

Пример 2.1(a) [Пример C]

Пример C: это не рекомендуется и может привести к сбою, поскольку аргументы scanf() должны быть указателями. Если вы хотите сохранить результат операции scanf() в стандартной переменной, перед ним должен стоять оператор ссылки, то есть знак амперсанда (&).

Пример C++: было выделено 100 мест. От 0 до 99. Изменение 100-го индекса приведет к сбою, поскольку он не существует. Это недопустимый индекс.

Пример 2.2(a) [Пример C]

(Помните, что индексы массивов в C и C++ начинаются с 0)

Заключение
Существует несколько способов выяснить, где программа вышла за пределы допустимого диапазона. Один из методов заключается в использовании printf(), cout или любых других средств вывода для вывода операторов и определения того, как далеко программа будет работать до того, как произойдет сбой, а также для вывода содержимого интересных переменных.

Напоследок: если вы столкнулись с «Ошибкой сегментации», это обычно означает то же самое, что и «Ошибка сегментации» или «Нарушение сегментации»; что все сводится к тому, что обычно это означает, что ваша программа пыталась получить доступ к памяти, которой у нее не должно быть, неизменно в результате повреждения стека или неправильного использования указателя.

Segmentation Fault: I is error, при которой работающая программа пытается получить доступ к памяти, не выделенной ей, и создает дамп ядра с ошибкой нарушения сегментации. Это часто вызвано неправильным использованием указателей, попытками доступа к несуществующему или доступному только для чтения адресу физической памяти, повторным использованием памяти, если она освобождена в той же области, разыменованием нулевого указателя или (в C) непреднамеренным используя переменную без указателя в качестве указателя.

Эта ошибка может появиться в Ubuntu в любой момент. Несколько дней назад, когда я выполнял свою рутинную работу на своем ноутбуке с Ubuntu, я внезапно столкнулся с ошибкой «Ошибка сегментации (дамп ядра)», после чего я узнал, что эта ошибка может поразить вас в Ubuntu или любой другой операционной системе в любое время. момент, так как сбой двоичных файлов не зависит от нас.

Ошибка сегментации возникает, когда ваша система пытается получить доступ к несуществующей странице памяти.Сброс ядра означает, что часть кода пытается выполнить операцию чтения и записи в доступном только для чтения или свободном месте. Сегментные сбои обычно связаны с файлом с именем core и обычно происходят во время обновления.

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

Вы можете выполнить возврат или отладку, чтобы решить эту проблему, но решение состоит в том, чтобы восстановить поврежденные пакеты, и мы можем сделать это, выполнив следующие шаги:

Командная строка:

Шаг 1. Удалите файлы блокировки, находящиеся в разных местах.

Шаг 2. Удалите кэш репозитория.

Шаг 3. Обновите и обновите кэш репозитория.

Шаг 4. Теперь обновите свой дистрибутив, он обновит ваши пакеты.

Шаг 5. Найдите сломанные пакеты и принудительно удалите их.

Помимо командной строки, лучший способ, который всегда будет работать, это:

Шаг 1. Запустите Ubuntu в режиме запуска, нажав клавишу Esc после перезагрузки.

Шаг 2. Выберите Дополнительные параметры для Ubuntu

Шаг 3. Запустите Ubuntu в режиме восстановления, и вы увидите множество вариантов.

Шаг 4. Сначала выберите "Восстановить поврежденные пакеты"

Шаг 5. Затем выберите «Возобновить обычную загрузку»

Итак, у нас есть два метода устранения ошибки сегментации: интерфейс командной строки и графический интерфейс. Иногда также может случиться так, что команда «apt» не работает из-за segfault, поэтому наш метод CLI не будет работать, в этом случае также не беспокойтесь, так как метод GUI будет работать для нас всегда.


Вопрос ниже о том, что может быть причиной "ошибок сегментации" (coredump)
(код возврата = 139) и "ошибок шины".

Описание проблемы:

В рамках нашего пакетного
цикла мы запускаем несколько программ COBOL. Главная бухгалтерская книга, предоставленная PeopleSoft, кредиторская задолженность,
закупки и так далее. однако из этой горстки модулей
ошибка затрагивает ТОЛЬКО ОДИН -- главную книгу.

Задания инициируются с мэйнфрейма (MVS) и выполняют сценарии на
сервере открытых систем (UNIX). Эти задания могут выполняться УСПЕШНО много
раз, где-то от 10 до 60 раз, но затем вдруг последующая партия
может случайным образом прерваться. Основными ошибками являются "ошибка сегментации"
или "ошибка шины".

Отклонено в PROC09 с кодом возврата = 139 (ошибка сегментации)
Отклонено в PROC04 с кодом возврата = 139 (ошибка сегментации)

Когда задание прерывается, оно просто повторно инициируется со стороны MVS на
этапе, на котором произошла ошибка, и завершается успешно. ПРИМЕЧАНИЕ. В этих
ситуациях, когда задания были запущены повторно, НЕ было НИКАКИХ изменений в
программе, среде, конфигурации, передаваемых аргументах и ​​т. д. он просто успешно завершился при повторной попытке.

Попытки решения:

Мы проконсультировались с PeopleSoft по этому вопросу, который мучил нас
в течение нескольких недель после обновления до PeopleSoft Release 8;
Однако прогресса нет. PeopleSoft не желает выходить
за пределы текущего уровня поддержки, если проблема не может быть воспроизведена на
ПОСЛЕДОВАТЕЛЬНОЙ основе. Опять же, эти абенды происходят случайным образом.

Не знаю, связана ли эта проблема с PeopleSoft, с ошибкой COBOL (Server Express),
или с UNIX. Может ли это быть связано с проблемой памяти? Я
предоставляю некоторые данные "vmstat", которые окружают времена некоторых из
абендов для вашего обзора.

ошибки диска страницы памяти procs
процессор
rbw swap free re mf pi po fr de sr s7 s8 s7 s7 in sy cs
us sy id
Mon Jan 6 16: 50:00 EST 2003
2 1 0 5278328 659088 3800 18030 20456 8 8 0 0 9 0 17 0 5055 40629
5919 31 34 36
0 3 0 5287416 6 1 164 0 490 320 0 6 0 6 0 6209 26650 5653
21 24 55
0 2 0 5281232 662240 3105 7058 18736 72 8 0 0 7 0 7 0 4081 21691 2559
39 19 43
Пн 6 января 16:41:00 EST 2003
2 3 0 5273232 654120 3556 8035 25632 16 0 0 0 18 0 8 0 6340 33407
5951 37 25 38
1 2 0 5281442 16186 23656 240 0 0 0 41 42 42 55 4975
37476 3677 30 25 45
2 1 0 5282336 658032 2811 13198 15160 72 8 0 0 8 0 8 0 9 9 31 464584 3 br />Пн, 6 января 16:42:00 EST 2003
2 0 0 5267616 644344 2861 4579 20272 120 16 0 0 12 0 18 0 4306 27143
2985 47 19 34
0 2 0 5271040 737592 2500 3791 19848 16 8 0 0 2 0 2 0 5519 23832 3817
30 17 53
0 0 0 5288496 761184 765 7251 88 16 0 0 0 2 0 2 0 2357 20717 2758
23 12 65
Пн 6 января 16:43:00 EST 2003
0 0 0 5282336 808976 3561 11009 18504 8 8 0 0 5 0 10 0 4922 20066
3442 18 24 58
0 0 0 5275568 856912 495 2414 2904 0 0 0 0 1 0 1 0 3232 7951 2478
17 6 78
0 1 0 5284024 885480 656 3002 16504 0 0 0 0 5 0 4 0 3629 18645 2873
21 10 69
Пн, 6 января, 16:44:00 по восточному стандартному времени 2003
0 2 0 5271384 942416 52 8 525 8 0 0 5 0 4 0 3029 43548 3065
13 13 74
0 0 0 5287416 910008 634 2832 2152 64 0 0 0 6 0 6 0 3450 58254 4916
23 12 64
>0 0 0 5287624 967440 1731 2057 344 200 16 0 0 15 5 15 9 2843 41656
2993 21 11 69
Пн, 6 января 16:45:00 EST 2003
0 1 0 5298328 9 1663 17499 2664 32 16 0 0 20 0 16 0 3876 43643 6932 25 31 44 0 2 0 5281368 930984 765 8964 2560 0 0 0 0 0 0 0 0 15 6 5381 4 16128 69
0 1 0 5284472 1025248 1395 17755 96 8 8 0 0 1 0 1 0 2559 31961 3999
24 24 52
Пн, 6 января, 16:46:00 EST 2003
0 3 0 5279272 1009928 979 10872 1136 979 10872 1136 96 8 0 0 5 0 5 0 2986 21320 3601
21 15 65
1 1 0 5284752 1009552 693 8703 128 40 0 ​​0 0 5 0 5 0 2756 17887 3506
20 12 68
0 0 0 5273264 979648 266 2719 832 0 0 0 0 0 0 0 0 2488 8195 2655
13 6 81
Пн, 6 января, 16:47:00 EST 2003
0 1 0 5241488 977224 1217 12185 1136 88 8 0 0 6 0 8 0 2854 29627 3929
22 18 59
0 0 0 5280848 979072 0 0 873 6 10057 0 2 1 0 2306 16722 3127
18 12 70
0 0 0 5278128 976592 812 9571 176 0 0 0 0 0 0 0 0 2697 18991 3771
19 13 68
Пн 6 января 16: 48:00 по восточному поясному времени 2003
0 1 0 5281688 991344 831 9884 1800 16 0 0 0 5 1 3 0 3888 22427 4811
25 15 60
0 0 0 5289832 6 5 5 5 5 06618 2014 805 4 0 2 0 2 1 3442 29261 4941
25 16 59
0 1 0 5285352 986696 584 7667 544 0 0 0 0 6 0 6 0 2976 64067 3948
36 17 47
Пн 6 января 16:49:00 EST 2003
1 6 0 5274568 699024 727 6336 16288 0 0 0 0 1 0 0 0 7621 55165 8947
39 22 40
0 1 0 52788 24 688080 636 2481 3920 8 8 0 0 1 0 1 0 3118 9568 2587
19 6 75
0 0 0 5301376 708048 339 4255 168 0 0 0 0 0 0 0 0
12 6 8 86
Пн 6 января 16:50:00 EST 2003

На какие области следует обратить внимание, чтобы решить
эти проблемы? Считаете ли вы, что это проблема PeopleSoft, и что мы должны
искать и передать PeopleSoft, что убедит их заняться этим
более подробно? Это проблема UNIX? Какие изменения можно/нужно
внести на стороне UNIX, чтобы потенциально решить проблему и/или устранить
сопутствующий фактор?

Будем БОЛЬШО признательны за любую информацию и/или советы, которые вы можете предоставить, исходя из
конкретного опыта решения этой проблемы или из вашего опыта
взаимодействия всего вышеперечисленного.

Вы можете ответить в группе новостей или, что предпочтительнее, направить на
мой адрес электронной почты:

Читайте также: