Удалите файл и восстановите /var
папка от Вашего резервного копирования.
Если у Вас нет резервного копирования, Вы могли бы сделать rpm -ivh --replacepkgs filesystem...rpm
переустановить об/мин "файловой системы". Это создаст пустую (!) иерархию папок / var. Перезагрузка впоследствии. Теперь, если приложение все еще не работает, потому что что-то отсутствует в / var, делают то же с его об/мин.
1-можно контролировать трафик в этом интерфейсе с помощью команды:
sudo tcpdump -i eth0 -s 1518 -XX -vv -n -w /tmp/trace_file.pcap
Попытайтесь соединиться и видеть, получает ли интерфейс какой-либо трафик.
2-Проверок, если можно получить доступ к другим машинам С этого сервера кроме к этому серверу с помощью eth0.
3-Проверок интерфейсное использование состояния: ethtool eth0
.
4-Проверок интерфейсное состояние с помощью sys файлов под /sys/class/net/eth0/*
5-Проверок Ваше состояние брандмауэра (активный или неактивный) и проверка правила если таковые имеются.
6-Проверок использование сообщений отладки ядра dmesg
и проверьте системный файл журнала/var/log/messages на любые ошибки/предупреждения.
Надежда это поможет!
ssh: connect to host myserver port 22: Operation timed out
. Для № 1 выше, я выполнил команду приблизительно в течение минуты, и это сказало15 packets received by filter, 0 packets dropped by kernel
. Выполнение во второй раз в течение 2 минут возвратило 0 пакетов для обоих. Для № 3 я получил этот вывод. Я не уверен который файлы искать в каталоге от № 4. Для № 5 нет никаких правил, ограничивающих трафик. Для № 6 я получил этот вывод о eth0. – Brandon Konkle 16 November 2010 в 17:36