Нуждаюсь в помощи генерируя дамп ядра от апачского segfault

Опция 2 требует наличия экземпляра и выполнения 24/7 (или по крайней мере во время объединения общего графика работ). Это не может иметь значения для Вас.

Я не уверен, возможна ли опция 3. Вы спрашиваете об установке Xen (или что-то) в Вашем экземпляре EC2 и затем создаете свои собственные "подвиртуальные" машины?

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

Преимущества:

  • Разработчики не конкурируют за вычислительные ресурсы (например, ЦП) на общей машине. Это не может иметь значения для Вас.
  • Можно изменить изображение (например, обновление операционной системы) и выпустить новую "версию", не требуя времени простоя для всех разработчиков.
  • Потенциальные сбережения, так как Вам не нужен экземпляр 24/7.

Недостатки:

  • Потенциал увеличил стоимость, так как у Вас могло бы быть 5 выполнений экземпляров (т.е. 5 разработчиков, работающих сразу) вместо 1.
  • Требует, чтобы у каждого разработчика был доступ к учетной записи AWS.

Если Вы думаете, что это правильно для Вас, то проблема учетной записи AWS может быть решена несколькими способами:

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

Я полагаю, что можно предоставить доступ запуска к AMI, обязательно не давая человеку root доступ однажды экземпляр в порядке. Но Вы хотели бы перепроверить это, так как это кажется, что Вы обеспокоены безопасностью.

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

2
задан 18 March 2010 в 21:00
2 ответа

Необходимо перекомпилировать программы с отладочной информацией.

Я записал маленькое практическое руководство по этой теме: http://alekseykorzun.com/post/5251031042/debugging-crashes-on-freebsd; это - конкретный FreeBSD, но могло бы выручить Вас.

-1
ответ дан 3 December 2019 в 16:07

Это может быть связано с проблемами, которые я нашел решение для создания дампа ядра на Centos (который основан на Redhat). Соответствующий ответ: здесь , хотя и для php-fpm, а не для apache.

Камнем преткновения для меня, и я подозреваю, что и для вас, является то, что если процесс изменил свои собственные привилегии выполнения, он не разрешено создавать файл дампа ядра, если только / proc / sys / fs / suid_dumpable не разрешает это. Смотрите информацию об этом ядре-контроль уровня здесь .

Если apache инициализируется как root и выполняет свои рабочие процессы с ограниченными привилегиями, на это может повлиять вышеуказанный параметр в дополнение к другим параметрам, которые необходимо установить (путь к дампу ядра , ограничение размера ядра и т. д.)

0
ответ дан 3 December 2019 в 16:07

Теги

Похожие вопросы