РЕШЕНИЕ:благодаря @GracefulRestart я смог определить проблему:
Я думаю, что моя ошибка заключалась в использовании одной и той же группы безопасности для нескольких экземпляров ec2 (, каждый из которых я сейчас деактивировал ). Во всяком случае, я запустил pgrep httpd
и увидел список из 7 возвращенных номеров. Затем запустил ps -aux
, чтобы просмотреть полный список запущенных процессов. В конце этого списка были все процессы httpd, возвращенные изpgrep httpd
(большинство из них имели apache
как user
, но не все ). Я убил каждого из них с помощью:
sudo kill -9 [PID]
Затем запустил sudo apachectl restart
, и все заработало.
Я нашел проблему, но она привела только к другой проблеме и, возможно, к ответу.
Ошибка «не удалось получить» показывает, что он пытается получить доступ к репозиторию i386, что неверно, поскольку используется дистрибутив amd64.
Добавление [arch=amd64] в запись sources.list для репозитория исправило ошибки.
Однако...
На ISO-образах Kali почти нет deb... Дистрибутив упакован в виде live CD с sources.list, указывающим на скользящий релиз. Кажется, нигде нет снимка репозитория времени сборки. Даже liveCD содержит файловую систему cramfs с полноценной ОС, но даже на ней нет deb.
Я не осознавал всю глубину «скользящих релизов» для Kali. Я умолчал об этом как о незначительной проблеме, когда они сделали это несколько лет назад :
.https://www.kali.org/news/kali-linux-rolling-edition-2016-1/
You might want to choose a point-release distribution if you fit these
statements:
...
- You prioritize stability above new look/feel/functionality
- You want a minimum of distraction/disturbance from update installation
Это означает, что когда я устанавливаю новые пакеты, либо я:
Думаю, я просто буду хранить резервные копии, снимки и использовать много --сухих -прогонов на apt.