Postgresql неполный стартовый пакет astra linux

Lazarus + Postgres: неполный стартовый пакет

Я создавал программу на Lazarus Pascal с использованием Postgresql на сервере. Раньше нормально работал со следующими строками для открытия БД.

 dbConn:= TPQConnection.Create(nil); dbConn.HostName := 'localhost'; dbConn.DatabaseName:= 'dbHRS'; dbconn.UserName:='mizk'; dbConn.Password:='123'; dbConn.Open; if dbConn.Connected Then OpenHRSDB := true else OpenHRSDB := False; 

Но как только я переключаюсь с локального хоста на IP-адрес сервера (в локальной сети), программа просто останавливается. Нет ошибок или предупреждений. Я понятия не имею, что происходит.

Вот некоторые связанные детали, которые могут помочь сузить проблему.

  1. я запускаю программу с рабочей станции в той же локальной сети, что и сервер.
  2. Обе машины работают под управлением Ubuntu 12.04 Desktop
  3. Я могу получить доступ к базе данных postgres на сервере с помощью PGAdmin III, так что я полагаю, что это не проблема брандмауэра.
  4. Я позволил postgresql из UFW и UFW отключен.
  5. Странно, когда брандмауэр отключен, я могу SSH сервер с терминала, используя рабочую станцию. Но когда он включен, я не могу

Сейчас меня больше всего беспокоит то, почему программа Pascal не работает, когда указан IP-номер, и что это за сообщение в журнале postgres.

Любые вклады действительно ценятся. Спасибо!

Изменить: вот больше информации:

Файл postgresql.conf содержит следующие строки:

Извините. Вот правильный журнал ПОСЛЕ включения регистрации. Файл журнала содержит это после того, как я выключил, перезапустил и запустил мою программу:

2014-03-06 18:28:23 IST LOG: система базы данных была закрыта в 2014-03-06 18:28:22 IST 2014-03-06 18:28:23 IST LOG: соединение получено: host=[local] 2014-03-06 18:28:23 IST LOG: неполный стартовый пакет 2014-03-06 18:28:23 IST LOG: система базы данных готова принимать подключения 2014-03-06 18:28:23 IST LOG: автозапуск запускается 2014-03-06 18:28:24 IST LOG: соединение получено: host=[local] 2014-03-06 18:28:24 IST LOG: соединение разрешено: пользователь = база данных postgres =postgres 2014-03-06 18:28:24 IST LOG: соединение получено: host=[local] 2014-03-06 18:28:24 IST LOG: соединение авторизовано: user= база данных postgres =postgres 2014-03-06 18:28:25 IST LOG: получено соединение: хост = [локальный] 2014-03-06 18:28:25 IST LOG: авторизовано соединение: пользователь = база данных postgres =postgres 2014-03-06 18:28:29 IST LOG: получено соединение: host=[local] 2014-03-06 18:28:29 IST LOG: неполный загрузочный пакет

Источник

Postgres. Что значит сообщение: неполный стартовый пакет

У меня Postgres 9.6 Portable. При старте приложения(Не самой базы, а именно разрабатываемого приложения, работающего с ней) постоянно сыпет в консоль сообщения (Примерно раз в 8-10 секунд):

Читайте также:  Руководство администратора linux автор немет эви снайдер гарт хейн трент

введите сюда описание изображения

В целом все отлично работает, но эти сообщения мозолят мне глаза. Плюс постепенно вытесняют сообщения консоли из области экрана. Что это значит и как это можно отключить?

Если он portable, думаю, надо глянуть где-то в папке с ним. Либо в каталоге с БД. Можно в postgresql.conf посмотреть. И там же, возможно переопределить куда будет выводиться. Если я всё правильно понял, то можно добиться, чтобы вместо консоли выводилось в файл.

1 ответ 1

Как воспроизводится данное сообщение

Необходимо послать пакет, который просто проверяет доступность порта, не открывая полноценного соединения с PostgreSQL, например с помощью nmap:

что в свою очередь будет отображено в логе как LOG: incomplete startup packet (СООБЩЕНИЕ: неполные стартовый пакет)

sudo tailf /var/log/postgresql/postgresql-9.4-main.log 2017-09-08 10:47:05 MSK 16539 [unknown]@[unknown] LOG: could not receive data from client: Connection reset by peer 2017-09-08 10:47:05 MSK 16539 [unknown]@[unknown] LOG: incomplete startup packet 

Таким образом можно сделать вывод, что причина в разрабатываемом приложении, которое в какой-то момент лишь проверяет, но не создаёт соединение с PostgreSQL.

Источник

Почему не запускается postgres 9.6?

После того как слил на слейв потокововый бекап и выставил права на папку, пытаюсь запустить. Вот что пишет:

2018-06-15 10:26:08.026 MSK [725] СООБЩЕНИЕ: запись REDO начинается со смещения 4A4/EA48450
2018-06-15 10:26:08.041 MSK [728] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет
2018-06-15 10:26:08.068 MSK [725] СООБЩЕНИЕ: согласованное состояние восстановления достигнуто по смещению 4A4/ED9EAB8
2018-06-15 10:26:08.069 MSK [725] СООБЩЕНИЕ: неверное магическое число 0000 в сегменте журнала 00000002000004A40000000E, смещение 14417920
2018-06-15 10:26:08.123 MSK [729] СООБЩЕНИЕ: начало передачи журнала с главного сервера, с позиции 4A4/E000000 на линии времени 2
2018-06-15 10:26:08.550 MSK [732] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:09.060 MSK [735] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:09.572 MSK [738] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:10.086 MSK [741] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:10.598 MSK [744] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:11.108 MSK [747] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:11.622 MSK [750] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:12.135 MSK [753] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:12.647 MSK [756] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:13.161 MSK [761] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:13.674 MSK [764] postgres@postgres ВАЖНО: система баз данных запускается
2018-06-15 10:26:13.678 MSK [724] СООБЩЕНИЕ: получен запрос на «вежливое» выключение
2018-06-15 10:26:13.678 MSK [729] ВАЖНО: завершение процесса считывания журнала по команде администратора
2018-06-15 10:26:13.682 MSK [726] СООБЩЕНИЕ: выключение
2018-06-15 10:26:16.706 MSK [724] СООБЩЕНИЕ: система БД выключена

Как понять что не нравится Postgres?

Читайте также:  Свой системный вызов linux

Бывает что после отключение питания на Linux серверах с 1С вообще ничего не запускается. База postgres поломана и кэш 1С тоже. Вот шаги как заново всё привести в рабочее состояние.

1. Запускаем postgres в сингл моде от пользователя postgres чтобы его не убил systemd по таймауту

root@1cserver:~# su postgres postgres@1cserver:~$ /usr/lib/postgresql/9.6/bin/postgres --single -c config_file=/etc/postgresql/9.6/main/postgresql.conf -D /var/lib/postgresql/9.6/main -P -d 1 2018-09-07 09:23:27.289 MSK [3421] DEBUG: запись о контрольной точке по смещению 23/36889418 2018-09-07 09:23:27.294 MSK [3421] DEBUG: redo record is at 23/3674B6A8; shutdown FALSE 2018-09-07 09:23:27.294 MSK [3421] DEBUG: next transaction ID: 0:18537840; next OID: 13492030 2018-09-07 09:23:27.294 MSK [3421] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0 2018-09-07 09:23:27.294 MSK [3421] DEBUG: oldest unfrozen transaction ID: 545, in database 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: oldest MultiXactId: 1, in database 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: commit timestamp Xid oldest/newest: 0/0 2018-09-07 09:23:27.294 MSK [3421] DEBUG: предел наложения ID транзакций равен 2147484192, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: предел наложения MultiXactId равен 2147483648, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: starting up replication slots 2018-09-07 09:23:27.294 MSK [3421] LOG: система БД была остановлена нештатно; производится автоматическое восстановление 2018-09-07 09:23:27.298 MSK [3421] DEBUG: resetting unlogged relations: cleanup 1 init 0 2018-09-07 09:23:27.507 MSK [3421] LOG: запись REDO начинается со смещения 23/3674B6A8 2018-09-07 09:23:27.515 MSK [3421] LOG: invalid record length at 23/368B5C50: wanted 24, got 0 2018-09-07 09:23:27.515 MSK [3421] LOG: записи REDO обработаны до смещения 23/368B5C28 2018-09-07 09:23:27.515 MSK [3421] LOG: последняя завершённая транзакция была выполнена в 2018-09-06 20:47:59.49413+03 2018-09-07 09:23:27.515 MSK [3421] DEBUG: resetting unlogged relations: cleanup 0 init 1 2018-09-07 09:23:27.941 MSK [3421] DEBUG: performing replication slot checkpoint 2018-09-07 09:23:27.985 MSK [3421] DEBUG: предел наложения MultiXactId равен 2147483648, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.985 MSK [3421] DEBUG: Граница членов мультитранзакции сейчас: 4294914944 (при старейшей мультитранзакции 1) PostgreSQL stand-alone backend 9.6.8 backend>
root@1cserver:/home/usr1cv8# kill -15 #ваш_пид_процесса root@1cserver:/home/usr1cv8# /etc/init.d/postgresql start [ ok ] Starting postgresql (via systemctl): postgresql.service.

2. Останавливаем непригодный 1С и чистим его кэш и конфигурациооные файлы и запускаем заново

root@1cserver:~# /etc/init.d/srv1cv83 stop root@1cserver:~# rm -rf /home/usr1cv8/.1cv8 root@1cserver:~# /etc/init.d/srv1cv83 start

3. Запускаем RAS и добавляем базы которые были у нас на сервере 1С

root@1cserver:~# /opt/1C/v8.3/x86_64/ras --daemon cluster root@1cserver:~# /opt/1C/v8.3/x86_64/rac cluster list cluster : 583eba18-b263-11e8-ed9e-309c239dab48 host : 1cserver port : 1541 name : "Локальный кластер" expiration-timeout : 0 lifetime-limit : 0 max-memory-size : 0 max-memory-time-limit : 0 security-level : 0 session-fault-tolerance-level : 0 load-balancing-mode : performance errors-count-threshold : 0 kill-problem-processes : 0 root@1cserver:~# /opt/1C/v8.3/x86_64/rac infobase create --cluster=583eba18-b263-11e8-ed9e-309c239dab48 --name=our_1c_db --dbms=PostgreSQL --db-server=1cserver --db-name=our_1c_db --locale=ru --db-user=postgres --db-pwd=our_postgres_db_password и так далее для каждой базы 1С что были на сервере

Источник

Читайте также:  Kali linux debian 32 bit

Сообщение Strage в журнале PostgreSQL «неполный стартовый пакет» при запуске в Kubernetes

У меня есть автономный сервер PostgreSQL, работающий на Kubernetes. Я заметил в журнале следующие сообщения:

incomplete startup packet 

Теперь я прочитал несколько статей в Интернете и StackOverflow, и мне кажется, что это может быть связано с клиентом, который пытается подключиться к службе, чтобы проверить ее статус. По этой причине я написал проверку работоспособности и готовности так:

readinessProbe: exec: command: - /postgresql/readiness.sh initialDelaySeconds: 45 timeoutSeconds: 5 periodSeconds: 10 livenessProbe: exec: command: - /postgresql/liveness.sh initialDelaySeconds: 45 timeoutSeconds: 5 periodSeconds: 10 

где скрипты /postgresql/liveness.sh это примерно так:

#!/bin/sh if [ $(ps -ef | grep -v grep | grep postgres | wc -l) -lt 11 ]; then exit 1 else exit 0 fi 

а также /postgresql/readiness.sh вот так:

#!/bin/sh su - user -c "/var/user/packages/postgres-11.9/bin/psql -p 2544 -d postgres -c \"SELECT 1\"" > /dev/null 2>&1 

Проблема в том, что я все еще вижу сообщение в журналах и не знаю, как проверить, работают ли два зонда. Любое предложение?

2 ответа

Я нашел проблему. Если вы развертываете PostgreSQL в Kubernetes и предоставляете его как службу на облачной платформе, вам необходимо использовать балансировщик нагрузки. Этот балансировщик нагрузки проверяет работоспособность вашего приложения, отправляя пакеты работоспособности на порт PostgreSQL, и, поскольку это недопустимая команда PostgreSQL, приложение отвечает сообщением выше.

IBM Cloud не предлагает решения этой проблемы, и я думаю, что это сообщение можно проигнорировать. Чтобы сделать это менее раздражающим, просто установите правильное значение для проверки интервала (в моем случае 60 секунд вместо 5). Чем выше значение, тем меньше он будет раздражать, но будет меньше реагировать на сбои.

Кроме того, чтобы избежать неконтролируемого зондирования Kubernetes, всегда предоставляйте:

В моем вопросе вы можете увидеть, как определить его для PostgreSQL. Единственное, что не упомянуто, — это стартовый зонд, который вы можете определить таким образом:

startProbe: exec: command: - /postgresql/liveness.sh initialDelaySeconds: 45 timeoutSeconds: 5 periodSeconds: 10 

для startProbe можно использовать тот же сценарий живучести, поскольку приложение можно считать запущенным, когда все процессы запущены и работают. Однако активный и запущенный процесс не означает, что он может принять соединение, и здесь срабатывает проверка готовности.

Источник

Оцените статью
Adblock
detector