Как перезапустить демон
В UNIX-подобных операционных системах процессы, осуществляющие сервисные функции и не имеющие пользовательского интерфейса, называют демонами. В виде демонов реализовано большое количество служебного программного обеспечения (планировщик задач, подсистема ведения логов, серверы СУБД и т.д.). Иногда тот или иной демон необходимо перезапустить.
Статьи по теме:
- Как перезапустить демон
- Как вывести из режима восстановления
- Как вернуть систему на день назад
Вам понадобится
- — доступ к целевой машине (физический или удаленный);
- — учетные данные root.
Инструкция
Войдите в систему на целевой машине с учетными данными пользователя root. При наличии физического доступа к компьютеру и работе в графической среде (KDE, Gnome, и т.д.) запустите эмулятор терминала, такой как XTerm или Konsole. Также можно переключиться в текстовую консоль при помощи нажатия комбинации клавиш Ctrl+Alt+Fx, где x — номер консоли. Если вход уже выполнен под пользователем, отличным от root, выполните команду su. Если к машине имеется доступ по SSH, используйте подходящую программу для подключения. В UNIX-подобных системах обычно установлен консольный клиент ssh. При работе под Windows можно применить программу PuTTY, свободно распространяемую на сайте putty.nl. Введите учетные данные root и начните сеанс работы.
Узнайте имя init-скрипта, соответствующего демону, который необходимо перезапустить. Обычно все подобные скрипты находятся в каталоге /etc/rc.d/init.d и имеют те же имена, что и обслуживаемые ими демоны. Просмотрите содержимое данного каталога при помощи файлового менеджера или команды ls. Если вы знаете примерное название демона, отфильтруйте вывод ls утилитой grep. Например, ls -1 /etc/rc.d/init.d | grep log
Узнайте о текущем состоянии перезапускаемого демона. Выполните команду вида:service
Перезапустите демон. Выполните команду вида:service
Завершите текущий сеанс. Введите команду exit. Нажмите Enter. Для завершения работы в текстовой консоли или отключения от сервера SSH также можно использовать команду logout.
Unix2019a/Фоновые процессы (демоны)
Демон (daemon, dæmon, божество) — программа в ОС семейства Unix, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем.
Демоны обычно запускаются во время загрузки системы. Типичные задачи демонов: серверы сетевых протоколов (HTTP, FTP, электронная почта и др.), управление оборудованием, поддержка очередей печати, управление выполнением заданий по расписанию и т.д. В техническом смысле демоном считается процесс, который не имеет управляющего терминала. Чаще всего (но не обязательно) предком демона является init — корневой процесс UNIX.
В системах Windows аналогичный класс программ называется службой (Services).
Название «демон» появилось ещё до Unix, в 1960-x годах в системе Project MAC. Названо в честь демона Максвелла из физики, занимающегося сортировкой молекул в фоновом режиме. Демон также является персонажем греческой мифологии, выполняющим задачи, за которые не хотят браться боги.
Типичным демоном является cron, использующийся для периодического выполнения заданий в определённое время. Регулярные действия описываются инструкциями, помещенными в файлы crontab и в специальные каталоги.
Процесс init
init (сокращение от initialization) — система инициализации в Unix-подобных системах, которая запускает все остальные процессы.
- Первый пользовательский процесс, работает как демон и обычно имеет PID 1.
- Запускается непосредственно ядром системы.
- Является пра-родителем всех пользовательских (userspace) процессов системы.
- Согласно Filesystem Hierarchy Standard, располагается по пути /sbin/init.
runlevels
Уровень выполнения (runlevel) — степень загрузки операционной системы. Вот как происходит инициализация системы: процесс init запускается и анализирует файл /etc/inittab. Следует отметить, что в BSD-подобных системах схема несколько отличается.
Пример файла /etc/inittab:
id:5:initdefault: si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 x:5:respawn:/etc/X11/prefdm -nodaemon
По умолчанию в системе использовано 7 уровней инициализации:
- 0 — остановка системы
- 1 — загрузка в однопользовательском режиме
- 2 — загрузка в многопользовательском режиме без поддержки сети
- 3 — загрузка в многопользовательском режиме с поддержкой сети
- 4 — не используется
- 5 — загрузка в многопользовательском режиме с поддержкой сети и графического входа в систему
- 6 — перезагрузка
Вы можете подумать, речь идёт о каких-то уровнях, через которые система проходит в процессе загрузки. Это не так. Представляйте себе уровень запуска как некую точку, в которую переходит система, загружаясь.
В большинстве Unix/Linux систем, узнать текущий уровень инициализации можно командами:
$ runlevel $ who -r
Набрав init n в терминале (с правами суперпользователя), где n — номер уровня инициализации, можно переключиться в любой из вышеперечисленных уровней.
Стартовые скрипты для каждого уровня находятся в каталогах с /etc/rc0.d до /etc/rc6.d, где цифра после rc соответствует номеру уровня инициализации.
$ ls /etc/rc5.d/ README S02acpid S02irqbalance S02thermald S04cups-browsed S01apport S02anacron S02kerneloops S02whoopsie S04saned S01binfmt-support S02atd S02nginx S03avahi-daemon S05grub-common S01php7.0-fpm S02atop S02rsync S03bluetooth S05ondemand S01rsyslog S02cron S02speech-dispatcher S03lightdm S05plymouth S01uuidd S02dbus S02sysstat S04cups S05rc.local
Обычно скрипты не дублируются для каждого уровня. В каталогах rcX просто ставятся симлинки на скрипты в /etc/init.d.
$ ls -l /etc/rc5.d/S02nginx lrwxrwxrwx 1 root root 15 Nov 28 19:56 /etc/rc5.d/S02nginx -> ../init.d/nginx
Сами скрипты в /etc/init.d обычно пишутся по шаблону и должны уметь принимать параметр start|stop|restart.
В именовании используется такая логика.
- S — скрипты для запуска (start)
- K — скрипты для остановки (stop)
- Номер задаёт порядок выполнения: чем меньше номер, тем раньше запускается скрипт.
Для автоматизации создания этих линков с правильными именами есть специальные утилиты. Например, в RedHat и Fedora используется программа chkconfig, в Debian — update-rc.d.
Есть также специальный скрипт /etc/rc.local, который выполняется во всех многопользовательских уровнях.
Современные альтернативы init
Сейчас существует множество систем, призванных заменить собой классический init.
Главный недостаток традиционного init — он запускал процессы последовательно, ожидая завершения предыдущего перед запуском следующего. Поэтому были разработаны альтернативные решения:
- launchd (в Mac OS X)
- Upstart (первоначально разрабатывалась в Ubuntu, ныне устарела)
- systemd (используется в современных Debian, Ubuntu, Fedora, . ; критикуется за отход от Unix-философии и сложность)
$ sudo readlink -f /proc/1/exe /lib/systemd/systemd
Классический файл /etc/inittab вообще отсутствует.
Способы запуска и остановки сервисов
Классический UNIX System V init:
$ sudo /etc/init.d/nginx start $ sudo /etc/init.d/nginx stop
$ sudo start nginx $ sudo stop nginx
$ sudo systemctl start nginx $ sudo systemctl stop nginx
$ sudo service nginx start $ sudo service nginx stop
Свой простейший демон на systemd
Добавляется конфиг /etc/systemd/system/foo.system:
[Unit] Description=foo [Service] WorkingDirectory=/home/ ExecStart=/usr/bin/env python -m SimpleHTTPServer [Install] WantedBy=multi-user.target
Затем установка и запуск:
$ sudo systemctl enable foo $ sudo systemctl start foo
7.2.6.3. Системные демоны и традиционные сигналы
Многие широко известные системные демоны в качестве сигнала для повторной инициализации (т.е. перезагрузки их конфигурационных файлов) принимают сигнал SIGHUP (первоначально данный сигнал отправлялся программам при разрыве последовательной линии, например при разрыве модемного соединения). Примеры включают в себя Apache и Linux-реализации таких демонов, как bootpd(8), gated(8), inetd(8), mountd(8), named(8), nfsd(8) и ypbind(8). В некоторых случаях сигнал SIGHUP принимается «в его первоначальном смысле», как сигнал разрыва сеанса (особенно в Linux-реализации pppd(8)), но эта роль в настоящее время, как правило, отводится сигналу SIGTERM.
SIGTERM (terminate — завершить) часто принимается как сигнал постепенного завершения (чем он отличается от SIGKILL, который выполняет немедленное уничтожение и не может быть блокирован или перехвачен). Данный сигнал часто вызывает очистку временных файлов, удаление последних изменений в базах данных и подобные действия.
При написании демонов рекомендуется придерживаться правила наименьшей неожиданности, т.е. использовать данные соглашения и читать справочные руководства для поиска существующих моделей.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Демоны bdflush и kupdated
Демоны bdflush и kupdated В ядрах серий до 2.6 работа потоков pdflush выполнялась двумя другими потоками ядра bdflush и kupdated.Поток пространства ядра bdflush выполнял фоновую обратную запись измененных страниц, когда количество доступной памяти становилось достаточно малым. Также был
Демоны syslogd и klogd
Демоны syslogd и klogd В стандартной системе Linux для извлечения сообщений ядра из буфера используется специальный демон пространства пользователя klogd, который направляет эти сообщения в файл журнала системных сообщений. Для чтения системных сообщений программа klogd может
12.1.4. Сигналы и системные вызовы
12.1.4. Сигналы и системные вызовы Часто сигналы доставляются процессу, который находится состоянии ожидания наступления некоторого внешнего события. Например, текстовый редактор часто ожидает завершения read(), чтобы возвратить ввод терминала. Когда системный
Демоны
Демоны Демоны — это неинтерактивные процессы, которые запускаются обычным образом — путем загрузки в память соответствующих им программ (исполняемых файлов), и выполняются в фоновом режиме. Обычно демоны запускаются при инициализации системы (но после инициализации
Глава 13 Процессы-демоны и суперсервер inetd
Глава 13 Процессы-демоны и суперсервер inetd 13.1. Введение Демон (daemon) — это процесс, выполняющийся в фоновом режиме и не связанный с управляющим терминалом. Системы Unix обычно имеют множество процессов (от 20 до 50), которые являются демонами, работают в фоновом режиме и
9.6.1. Традиционные средства печати UNIX
9.6.1. Традиционные средства печати UNIX Исторически для печати в UNIX-системах существовали две системы печати: LPD (Line Printer Daemon) [RFC1179], разработанная для Berkeley UNIX (или BSD-система), и ATT Line Printer system. Эти системы печати были созданы в 70-х годах для печати текстов на построчно-печатающих
12.2.1 Традиционные средства UNIX для просмотра текстовых файлов
12.2.1 Традиционные средства UNIX для просмотра текстовых файлов Самым простым средством просмотра файла является, наверное, команда cat. Выведя содержимое текущего каталога с помощью команды ls, вы можете также вывести на экран содержимое любого из имеющихся файлов командой
1.7.6. Порты и демоны
1.7.6. Порты и демоны Дальнейшее изложение материала построено, исходя из того, что вы уже знаете, что такое сервер и какие службы вам придется настраивать. В пункте Как устроена книга (п. 1.5) было подробно описано, в каких главах описана настройка той или иной службы. Здесь же
Традиционные операции над множествами и оператор SELECT
Традиционные операции над множествами и оператор SELECT Традиционные операции над множествами — это объединение, пересечение, разность и декартово произведение. Декартово произведение Ранее мы уже рассмотрели реализацию декартова произведения, перечисляя через запятую
nik Color Efex Traditional filters (Традиционные фильтры)
nik Color Efex Traditional filters (Традиционные фильтры) Фильтры пакета nik Color Efex Pro можно также разделить на группы, каждая из которых включает несколько эффектов. Это аналогичные по действию фильтры, которые имеют схожие настройки и незначительные различия в характере эффекта. В
7.2.6.3. Системные демоны и традиционные сигналы
7.2.6.3. Системные демоны и традиционные сигналы Многие широко известные системные демоны в качестве сигнала для повторной инициализации (т.е. перезагрузки их конфигурационных файлов) принимают сигнал SIGHUP (первоначально данный сигнал отправлялся программам при разрыве
3.3. Сигналы
3.3. Сигналы Сигналы — это механизм связи между процессами в Linux. Данная тема очень обширна, поэтому здесь мы рассмотрим лишь наиболее важные сигналы и методики управления процессами.Сигнал представляет собой специальное сообщение, посылаемое процессу. Сигналы являются
Традиционные модульные структуры
Традиционные модульные структуры Наряду с требованиями к модульности, изложенными в предыдущей лекции, пять требований Изменчивости Типов, Группирования Подпрограмм, Изменчивости Реализаций, Независимости Представлений и Факторизации Общего Поведения определяют,
Класс для реализации UNIX-демонов на PHP
Честно, не вдавался в подробности сигналов. Почитаю на досуге подробней, исправлю и закомичу в репу. Там же вроде SIGTERM нужно посылать?
Всего голосов 9: ↑1 и ↓8 -7
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
От целей зависит. Мне вот субъективно кажется, что в рассматриваемом случае KILL вполне уместен.
Всего голосов 2: ↑0 и ↓2 -2
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В смысле демон на PHP по определению настолько убог, что ему никогда не потребуется выполнить какую-либо зачистку перед остановкой?
Всего голосов 3: ↑3 и ↓0 +3
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Да, можно и так читать.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
9-й сигнал, к сожалению, и правда лучше как можно реже использовать — потому что не все ресурсы IPC, занятые процессом, освобождаются при такой смерти. Например, семафоры и страницы shared memory нужно явно освобождать (что демоны часто делают в своих обработчиках смертельных сигналов). Я сам в такое не верил, пока не убедился на собственном опыте (в моем случае в какой-то момент ни одного процесса apache в живых не осталось, т.к. я все убил по 9-му сигналу, но ресурсы занимались и переполнились — man ipcs).
Всего голосов 6: ↑6 и ↓0 +6
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Вот с этим точно не поспоришь — на неосвобожденные IPC’шные очереди и семафоры, например, я и сам насмотрелся, была возможность.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Да раз уж метод stop() называется, вполне логично kill -9 послать. Вот если бы был метод kill(), то аргумент с номером сигнала был бы очень уместен.
Всего голосов 3: ↑0 и ↓3 -3
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Речь не о том, чтобы кастомизировать посылаемый сигнал. Разницу между SIGKILL и SIGTERM знаете?
Всего голосов 4: ↑4 и ↓0 +4
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Исправил на SIGTERM. Проверил. Закоммитил.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Знаю конечно. Вы когда процесс убиваете обычно, просто kill ему шлете? У меня вот стопроцентная привычка: если уж дошло до убийства, то KILL и послать. Понятно, что у вас могут быть умные красивые демоны, которые в ответ на SIGTERM запишут логи, дампы, отправят отчет по e-mail и xmpp и мирно завершатся. Ну тогда и измените метод stop().
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Вот над этим нужно подумать еще. Как бы это первая еще «сырая» версия. Я по-этому и опубликовал, чтобы узнать мнение чего здесь не хватает.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Есть набор соглашений, которых рекомендуется придерживаться при разработке демонов. SIGTERM для завершения, SIGHUP для обновления конфигурации и тп.
Правильный демон можно использоваться совместно с системой типа launchd или xinetd — и получать такие плюшки как on demand запуск и автоматический рестарт при падении.
Всего голосов 3: ↑3 и ↓0 +3
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Ну так-то оно так, но это скорее уже к системным сервисам относится, чем к демону как таковому.
Здесь, как я понимаю, автор привел схему простейшей демонизации php-скрипта, главнейшая цель которой — отвязать скрипт от терминала и дать ему работать в фоне «вечно». Со своими обязанностями класс справляется.
Предложенные вами вещи конечно неплохо бы дописать(коль уж вываливаем на всеобщее обозрение в репозитарий), но пусть они тогда будут отключаемыми.
Ну может конфиг при создании класса передавать какой с настройками.
У меня еще при стартах демонов выполняются такие вещи:
ini_set("max_execution_time", "0"); ini_set("memory_limit", "-1"); ob_implicit_flush(); define("IS_WIN", (stristr(php_uname('s'), 'windows')==FALSE)?false:true);
Если IS_WIN, то демонизация не происходит — запускается просто как консольный скрипт. Винда — это отладочный полигон.
Ну и еще допишу, это уже не на ваш комментарий, а автору поста на заметку(лениво новый камент писать).
У меня при создании подробнейших логов(tcp-сервер все-таки, писать в логи всегда есть чего) как-то обнаружилось, что логи больно дофига места занимают. И соответственно потом при жалобах, что кто-то чего-то не смог разобраться в системе, когда надо лезть в логи и смотреть, чего там юзер куда клацал и куда ломился, оказывается, что скакать по большим логам в общем-то удовольствие сомнительное.
Поэтому были дописаны некоторые авто-функции:
Тыц сюда
function gen_log_subdir() < $tmv=time(); return sprintf('%08X_', $tmv).date("dmY_His", $tmv); >function check_log_subdir($tsize=100000000) < $root=$this->log_dir.$this->log_subdir; $res=0; if ($dir = @opendir($root)) < while (($file = @readdir($dir)) !== false) < $fn=$root.$file; if (is_file($fn)) < $res+=@filesize($fn); if ($res>$tsize) break; > > @closedir($dir); > $this->log_add=sprintf('%10u', $res); return ($res <$tsize); >function get_log_subdir() < $suf=($this->log_subdir=='')?'_':''; while ($this->log_subdir=='' || !$this->check_log_subdir()) < $this->log_subdir=$this->gen_log_subdir().$suf.'/'; > $lsd=$this->log_dir.$this->log_subdir; if (!file_exists($lsd)) mkdir($lsd); return $this->log_subdir; > function log_subdir() < return $this->log_dir.$this->get_log_subdir(); > function print_log($str) < $this->log_file=$this->log_subdir()."daemon.log"; $fp = @fopen ($this->log_file, "ab"); if (!$fp) return false; if (@flock($fp, LOCK_EX)) < if ($str!='') $str=date("[d-m-y H:i:s] ").'['.$this->log_add.']'.$str; fputs ($fp, $str."\n"); @flock($fp, LOCK_UN); > else < @fclose ($fp); return false; >@fclose ($fp); return true; >
Привожу их как есть, красиво форматировать «для всех» некогда. Впрочем это просто идея, реализация может быть и другой, более продуманной.
Смысл этих функций — писать логи, разбивая их на куски.
То есть мы при старте создаем субдиректорию с человекочитаемой временной меткой и символом ‘_’ в конце имени, пишем в нее логи. Как только размер логов в этой субдиректории достигают заданного размера, мы генерим новую субдиректорию с временной меткой в имени, но уже без ‘_’ в конце, и продолжаем писать логи уже в нее. И так далее.
Метка ‘_’ в имени ставится только первой субдиректории при старте демона, поэтому глядя в подкаталог логов можно сразу видеть в какое время был старт(рестарт) демона.
Если нужно найти логи за определенное время, в списке поддиректорий сразу можно понять, в какую надо идти и какой лог смотреть. Это удобнее, чем гигабайтные портянки логов листать.
Подробные логи всегда дублируются общим неподробным. Туда пишутся только имена пришедших комманд и временные метки. В результате на 100метровую директорию неподробный лог метра четыре весит. По нему быстро можно глянуть, в какое точно время началась активность нужного юзера, а потом уже по этой метке найти в подробном логе все параметры комманд, ответы сервера и т.п.
Пример листинга директорий с логами
4EC2691D_15112011_162901_ 4EC67040_18112011_174832 4ECCC14D_23112011_124757 4ED24B49_27112011_173801 4EDD37F5_06122011_003029 4EE1ACA0_09122011_093720 4EE71107_13122011_114703 4EEC5EEC_17122011_122044 4EF086F2_20122011_160034 4EF33912_22122011_170506 4EF73ED1_25122011_181841 4EF9AC85_27122011_143117 4EFBBD1F_29122011_040639 4EFDD4F1_30122011_181249 4F02CB36_03012012_123238 4F09DBA9_08012012_210841 4F0ED584_12012012_154348 4F15046A_17012012_081730 4F1A7124_21012012_110244 4F1FA0B1_25012012_092657 4F24ECC9_29012012_095257 4F28E8F9_01022012_102545 4F2E7DBE_05022012_160150 4F32BCD4_08022012_212004 4F3810BF_12022012_221927 4F3CD2EE_16022012_125702 4F42007B_20022012_111243 4F475F9E_24022012_125958 4F4C8C59_28022012_111209 4F50E0EB_02032012_180203 4F55E8A6_06032012_133622 4F5739F0_07032012_133528_ 4F5754EA_07032012_153034 4F5B9B13_10032012_211859 4F5CEAAB_11032012_211051 4F6192AD_15032012_095645 .
Первые 8 HEX-символов это unix timestamp, который далее идет расшифрованным, как [uts_дата_время].
По меткам ‘_’ видим, что демон стартовал 15.11.2011 в 16:29:01, работал несколько месяцев, был перезапущен 07.03.2012 в 13:35:28 (обновление исходников, поддержка новых комманд).
В основном коде сервака вызывается только функция print_log(), как-то так:
$daemon->print_log("alarm! very important tcp-client connected") ;
А там оно само разбирается, в какой лог в какой поддиректории писать.
В результате(пример из реальных данных) в неподробном логе появляется что-то типа:
[04-06-12 15:43:00] [ 19410][check_logged_in 1CE9020C55E72313CD0EDEF5E3AC3058] :KEY_9 [04-06-12 15:43:00] [ 24273][db_set_value 1CE9020C55E72313CD0EDEF5E3AC30585F1A34060BD5|confirmed|1] :KEY_9
А в подробном такое(две принятые комманды и отосланные ответы на них):
Тыц мышей
[06-04-12 15:43:00] received from 192.168.50.18:3060 [KEY_9]: 0x00000000 2A 00 00 37 00 00 00 01 00 00 00 00 00 00 00 00 *..7. 0x00000010 04 00 00 0F 63 68 65 63 6B 5F 6C 6F 67 67 65 64 . check_logged 0x00000020 5F 69 6E 04 00 00 20 31 43 45 39 30 32 30 43 35 _in. 1CE9020C5 0x00000030 35 45 37 32 33 31 33 43 44 30 45 44 45 46 35 45 5E72313CD0EDEF5E 0x00000040 33 41 43 33 30 35 38 3AC3058 Data: array ( 0 => 'check_logged_in', 1 => '1CE9020C55E72313CD0EDEF5E3AC3058', ) [06-04-12 15:43:00] sended to 192.168.50.18:3060 [KEY_9]: 0x00000000 2A 9B 00 0C 00 00 00 01 00 00 00 00 00 00 00 00 *›. 0x00000010 02 00 00 02 00 C8 04 00 00 02 4F 6B . И. Ok Data: array ( 0 => 200, 1 => 'Ok', ) [06-04-12 15:43:00] received from 192.168.50.18:3060 [KEY_9]: 0x00000000 2A 00 00 52 00 00 00 01 00 00 00 00 00 00 00 00 *..R. 0x00000010 04 00 00 0C 64 62 5F 73 65 74 5F 76 61 6C 75 65 . db_set_value 0x00000020 04 00 00 2C 31 43 45 39 30 32 30 43 35 35 45 37 . 1CE9020C55E7 0x00000030 32 33 31 33 43 44 30 45 44 45 46 35 45 33 41 43 2313CD0EDEF5E3AC 0x00000040 33 30 35 38 35 46 31 41 33 34 30 36 30 42 44 35 30585F1A34060BD5 0x00000050 04 00 00 09 63 6F 6E 66 69 72 6D 65 64 04 00 00 . confirmed. 0x00000060 01 31 .1 Data: array ( 0 => 'db_set_value', 1 => '1CE9020C55E72313CD0EDEF5E3AC30585F1A34060BD5', 2 => 'confirmed', 3 => '1', ) [06-04-12 15:43:00] sended to 192.168.50.18:3060 [KEY_9]: 0x00000000 2A E3 00 17 00 00 00 01 00 00 00 00 00 00 00 00 *г. 0x00000010 02 00 00 02 00 C8 06 00 00 0D 04 00 00 02 49 44 . И. ID 0x00000020 02 00 00 03 01 09 98 . Data: array ( 0 => 200, 1 => array ( 'ID' => 67992, ), )
Заголовок пакета — 16 байт. То есть каждая первая строчка HEX-лога.
Все, что передано в пакете после заголовка, «расшифровывается» сразу за дампом пакета.