Как уже говорили другие, grep -v '^. $'
отфильтровывает строки, состоящие ровно из одного символа (строки, состоят из начала строки ( ^
), за которым следует один символ (.
), за которым следует конец строки ( $
). Другой способ записи это будет grep -vx.
, где -x
делает ^
и $
неявными (.
совпадает со всей строкой).
На выходе:
find /ddomain/data/shop12/ -mtime +15 -print
Это не имеет особого смысла, потому что выходные данные этой команды find
обычно состоят из таких строк, как:
/ddomain/data/shop12/foo
/ddomain/data/shop12/foo/bar
...
Единственный способ для этого вывод, содержащий строки с одним символом, - это если есть файл с именем вроде foo
. Это вполне возможно, но я бы сказал, что вряд ли это было намерением этого команда.
Возможно, эта команда была (неправильно) адаптирована из:
find . -mtime +15 -print | grep -v '^.$' | grep data-
Где этот grep
предназначался для фильтрации . Запись
(даже тогда grep -Fvx.
было бы более подходящим). Однако тогда было бы разумнее написать его:
find . ! -name . -path '*data-*' -mtime +15
Если вы хотите отфильтровать каталог верхнего уровня с помощью find / ddomain / data / shop12 /
, вы должны сделать это как :
find /ddomain/data/shop12/. ! -name . -path '*data-*' -mtime +15
Или, если ваша реализация find
поддерживает предикат -mindepth
:
find /ddomain/data/shop12/ -mindepth 1 -path '*data-*' -mtime +15
Может быть одна из пятнадцати миллиардов причин. Некоторые из них перечислены ниже:
Проблема в том, что с только предоставленной информацией абсолютно невозможно провести какую-либо дальнейшую диагностику, что делает этот вопрос «слишком широким» (помеченным как таковой ).
[edit] My other devices can ping my PC, but my PC can not ping any other device including the router to which my PC is attached directly.
Я бы проверил наличие конфликтующего IP-адреса на другом устройстве.
(Хотя я не уверен, что ваши результаты ping
согласуются с этим. Это не совсем соответствует моим представлениям об ARP, и, к сожалению, я не нашел похожей комбинации в результатах поиска Google. Возможно, есть дополнительная проблема или другая проблема. Но это неплохо проверить, и это может помочь вам найти какую-то подсказку ).
Найдите на своем ПК MAC-адрес («аппаратный адрес» ). Если вы запустите ip link show dev eth1
, MAC-адресом будет значение, показанное после link/ether
.
На одном из других устройств внимательно проверьте, какой MAC-адрес закеширован для вашего IP-адреса, 192.168.0.146. Если другое устройство работает под управлением Linux, вы можете проверить кэш ARP с помощью ip -4 neigh
. Если другое устройство работает под управлением Windows, вы можете проверить кэш ARP, используяarp -a
(в командной строке Windows). Если он показывает другой MAC-адрес для вашего IP-адреса 192.168.0.146, то на самом деле вы пинговали другое устройство, а не свой ПК :-).
Предыдущая версия:
AfroJoe: so many reasons
С технической точки зрения, ping
сообщение «Назначенный хост недоступен» является довольно специфичным сообщением об ошибке! Ваш вывод почти наверняка означает, что разрешение ARP не работает. На 192.168.0.146
. Похоже, это был тот же компьютер, на котором вы запускали ping
, и вы подтвердили это в более позднем редактировании. В этом случае вот как подтвердить проблему с ARP:
$ ping 172.16.8.2
PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data.
From 172.16.8.205 icmp_seq=1 Destination Host Unreachable
From 172.16.8.205 icmp_seq=2 Destination Host Unreachable
From 172.16.8.205 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.8.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 4
$ ip -4 neigh
172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE
172.16.8.2 dev wlp2s0 INCOMPLETE
Успешное разрешение ARP включает такой обмен:
$ sudo tcpdump -n -i wlp2s0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28
13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28
13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64
13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64
13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64
13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel
(наблюдается при запуске ping и принудительном обновлении ARP с помощьюip neigh flush dev wlp2s0
).
Примечание :эта интерпретация в основном применима только к ping
. Он не применяется, когда вы получаете сообщение «Host Unreachable» от «нормального» приложения TCP/IP, такого как ssh
или curl
, потому что это также может означать, что вы получили ответ об ошибке ICMP, такой как «Административно запрещено» (из брандмауэра ). Однако ping
получает и декодирует весь ответ ICMP. Таким образом, ping
сообщит вам, что ошибка была конкретно «Административно запрещена», а не , а просто «Хост недоступен».
Кроме того, эти вопросы и ответы касаются IPv4. Я не проверял, как его можно адаптировать для IPv6.
AfroJoe: so many reasons
У меня есть еще одно секретное знание. Если ваша клиентская система Ubuntu не была кем-то преднамеренно настроена, адрес 192.168.0.146
был назначен посредством обмена DHCP-пакетами. Обычно в этом обмене участвует маршрутизатор, хотя в других случаях он может включать только Windows Server или сервер другого типа. В этом случае, когда маршрутизатор является DHCP-сервером или ретранслятором, ваша система уже могла обмениваться некоторыми пакетами с маршрутизатором .
Вы можете проверить повторно -инициирование обмена DHCP, разорвав и повторно -установив соединение.[ *] Конечно, если проблема продолжает возникать снова "случайно", это не решает основную проблему. проблема,и вы можете захотеть исследовать соединение, пока оно все еще разорвано.
([ *] Apple написала оптимизацию, которая может выполнять обмен DHCPпосле обмена определенными пакетами ARP . Возможно, с этим есть новые причуды, но я еще не видел, чтобы это использовалось в Linux.)
Эта ошибка часто возникает при подключении с использованием DHCP и WiFi, когда в какой-то момент теряется сигнал беспроводной сети. (И вы заметили это до того, как беспроводный уровень полностью отказал... Я не знаю, почему я видел это так много раз, возможно, я наблюдал глючные или плохо написанные системы ). Но eth1 не является WiFi-соединением.
Я считаю, что DHCP для IPv4 работает без запроса ARP. По крайней мере, при первоначальном обмене DHCP.
Судя по фактам в первоначальной версии вашего вопроса, я изо всех сил пытался придумать какой-либо отдельный сценарий, который особенно распространен. (Включая мои неявные предположения. Маловероятно, что кто-то опубликует этот вопрос без попытки подключить свой компьютер к работающему маршрутизатору ).
192.168.0.1
. Если это то, что дало вам DHCP-адрес, то он был удален из сети. Отключился или просто умер. ethtool
).