Странно...
Я вот задумался, а что происходит у провайдера в логах при смене IP?
Даже при использовании браузеров типо Тора.
Ведь провайдер передаёт эти данные, значит логи должны сохраняться. И знать кому передают, сколько IP не меняй, он же знает куда идут данные.
Так вот, почему у нас всех пользователей сайтов.... В честь "древнегреческих монстров" еще не пересажали?
Я чет не совсем догоняю эту тему.
Расшифровка логов ошибок iPhone с помощью нейросети
Расшифровать логи и понять куда копать при глюках iphone, например при перезагрузках через каждые 3 минуты, в наше время можно с помощью нейросети. В моем случае это была DeepSeek.
Открыть логи можно через Аналитику (Настройки/конфиденциальность/Аналитика/Данные аналитики). Ниже пример
Затем успейте передать скрин лога на устройство, где есть DeepSeek.
В DeepSeek нажмите на "+" и прикрепите скрин выбрав "изображение OCR" и дайте запрос на расшифровку ошибки айфона:
Нейросеть выдаст подробную информацию при расшифровке лога:
Вот цитата:
### **Расшифровка ошибки из лога `panic-full`**
Ваш iPhone перезагрузился из-за **критического сбоя ядра (Kernel Panic)**, вызванного проблемой с системой мониторинга температуры и датчиками. Вот ключевые детали:
### **Основная причина**
**`userspace watchdog timeout: no successful checkins from thermalmonitored (2 induced crashes)`**
- Система **thermalmonitored** (отвечает за контроль температуры) перестала отвечать, что привело к аварийной перезагрузке.
- Указан проблемный датчик: **`Missing sensor(s): mic1`** — возможно, неисправен микрофон или его температурный сенсор.
### **Дополнительные симптомы**
1. **Неисправность датчиков**:
- Ошибка указывает на отсутствие данных с датчика **`mic1`** (микрофон 1). Это может быть связано с:
- Физическим повреждением (например, после попадания влаги).
- Отсоединением шлейфа (если iPhone падал или разбирался).
2. **Проблемы с системными процессами**:
- В логе упоминаются службы (`backboardd`, `SpringBoard`, `audiomxd` и др.), но они работали нормально. Сбой произошел именно в модуле контроля температуры.
3. **Аппаратный конфликт**:
- Версия SOC (чипсета) — **T8030** (это A13 Bionic, используется в iPhone SE 2/3, iPhone 11).
- Возможен перегрев или нестабильность чипа из-за:
- Износа батареи (она может перегреваться).
- Замыкания в цепи датчиков.
### **Что делать?**
#### 1. **Проверьте батарею**
- Перейдите в *Настройки → Аккумулятор → Состояние аккумулятора*.
- Если износ **выше 80%** — замените батарею (она могла вызвать перегрев).
#### 2. **Охладите iPhone**
- Если устройство перегревается (например, при играх или зарядке), дайте ему остыть.
#### 3. **Сбросьте настройки**
- Попробуйте сбросить все настройки (*Настройки → Основные → Сброс → Сбросить все настройки*).
#### 4. **Обновите iOS**
- В логе указана версия **iOS 18.4.1 (22E252)**. Проверьте, доступны ли обновления (*Настройки → Основные → Обновление ПО*).
#### 5. **Проверьте микрофон**
- Запустите диктофон или позвоните через громкую связь. Если микрофон не работает — вероятна аппаратная поломка.
#### 6. **Диагностика в сервисе**
- Если проблема не решается, обратитесь в Apple Support или авторизованный сервис. Ошибка указывает на возможную **неисправность датчиков или материнской платы**.
### **Вывод**
iPhone перезагружается из-за сбоя в системе контроля температуры, связанного с датчиком микрофона. Это может быть как программный баг (исправляется обновлением), так и аппаратная поломка (требует ремонта). Начните с проверки батареи и микрофона, затем обратитесь в сервис, если проблема сохраняется.
С этой инфой уже пойду в СЦ. Есть понимание, что это не контроллер заряда с ремонтом в 7к рубасов, как мне в одной шаражке сказали.. Т.к. 7к это цена данного телефона на авито.
Надеюсь паста была полезной, и как говорят милениалы: "Всем бобра!"
"Серверные призраки: когда техника ведёт себя странно"
Введение: Когда логи не объясняют аномалии
Каждый сисадмин сталкивался с ситуациями, которые нельзя объяснить рационально. Серверы, которые сами перезагружаются по ночам, свитчи, передающие пакеты с выключенных портов, и жёсткие диски, на которых данные появляются из ниоткуда.
В этой статье мы соберём самые загадочные истории из мира IT, которые не поддаются логике. Возможно, это просто баги. А может, в сети живёт что-то ещё…
Глава 1. "Фантомные процессы" – кто запускает то, чего не должно быть?
1.1. Таинственный PID 666
Один администратор рассказывал, что на его сервере периодически появлялся процесс с PID 666, который исчезал при попытке его убить. В логах не было ни имени, ни владельца – только пустота.
Теория 1: Это демон (в прямом и переносном смысле), который мониторит систему.
Теория 2: Артефакт ядра ОС особенно Linux, который проявляется только при определённых условиях.
1.2. Процесс [kworker/0:0], который нагружает CPU на 100%
Многие видели его, но никто не знает, чем он на самом деле занимается.
Миф: Если попытаться его остановить, система зависнет.
Реальность: Это часть ядра, но иногда он ведёт себя слишком активно без причины.
Глава 2. "Сеть, которая помнит" – аномалии маршрутизации
2.1. Пакеты с несуществующего IP
Бывали случаи, когда сервер получал SYN-запросы с IP-адресов, которых никогда не существовало в этой подсети.
Объяснение?
Ошибка ARP-кэша?
Кто-то эмулирует трафик?
Или сеть "помнит" старые адреса?
2.2. Свитч, который передаёт данные без питания
История из форума: после аварийного отключения электричества один свитч продолжал мигать и даже пропускал трафик, хотя был физически отключён от сети.
Возможные причины:
Остаточный заряд в конденсаторах?
Или что-то более странное?
Глава 3. "Жёсткие диски, которые знают слишком много"
3.1. Файлы, которые возвращаются после удаления
Один администратор клялся, что удалил лог-файл, но через неделю он снова был на месте. Проверка fsck не показала ошибок, а inode был новым.
Мистика или баг?
Возможно, это работа скрытого бекап-скрипта.
Или файловая система "помнит" слишком много.
3.2. Диск, который "предсказывает" ошибки
Некоторые HDD начинают сыпать SMART-ошибками за несколько дней до реального падения. Но есть случаи, когда диск выдавал предупреждения, потом работал годами, а в итоге умирал ровно в предсказанный день.
Глава 4. "Сервер, который не хотел умирать"
4.1. Машина, которая загружалась без процессора
На одном форуме описан случай: сервер продолжал работать (с ошибками, но работал!) после того, как из него вынули CPU.
Как? Возможно:
Остаточные заряды в кэше.
Ошибка BMC/IPMI.
Или сервер никогда не был настоящим…
4.2. Система, которая отвечала после rm -rf /
Один бедолага случайно удалил корень, но сервер продолжал работать. Оказалось, что некоторые процессы остались в памяти, а init не завершился.
Мораль: Даже после апокалипсиса Linux может держаться.
Заключение: "Вы уверены, что это просто глюк?"
IT-инфраструктура — сложная штука, и иногда она ведёт себя так, как не должна. Но что, если некоторые аномалии — не баги, а особенности?
Совет: Если ваш сервер начинает вести себя странно — сначала проверьте логи. А если их нет… может, лучше не копать глубже?
P.S. Если у вас есть подобные истории — пишите в комментарии. Но помните: иногда техника знает больше, чем нам кажется.
Лог действий почты mail.ru перестал показывать город
У меня в почте mail.ru лог действий перестал показывать город и вместо указания города, пишет ip адрес и Россия, город не указан!
Как так?! Ранее показывал: ip адрес, город, устройство, время, и какое действие производилось.
Мобильный оператор связи Мегафон.
Почта>настройки>безопасность>лог действий
И как мне сейчас отслеживать наличие посторонних в почте?
У вас тоже есть этот баг?