Не запускається служба postgresql 8.4. Не запускається служба PostgreSql. Що робити? Параметри, специфічні для Windows

Я намагаюся запустити Postgres 9.2.4 як служба у Windows 7. Після встановлення postgres служба працює нормально. Однак після встановлення postgres як сервер для іншої програми служба перестала працювати. Коли я намагаюся запустити сервіс зараз, я отримую повідомлення про те, що:

"Служба postgresql-x64-9.2 - PostgreSQL Server 9.2 на локальному комп'ютері Комп'ютер почав, а потім зупинився. Деякі служби автоматично зупиняються, якщо вони не використовуються іншими службами або програмами".

Коли я намагаюся запустити програму, яка повинна використовувати сервер бази даних, я отримую цю помилку:

"Проблема виникла при спробі увійти в систему або створити виробничу базу даних. Подробиці: не вдалося підключитися до сервера; Міг не підключатися до віддаленого роз'єму. Програма повинна тепер закрити"

Я також зіткнувся з цією помилкою один раз при відкритті однієї програми.

"Проблема виникла при спробі увійти в систему або створити виробничу базу даних. Подробиці: FATAL: не вдалося завантажити pg_hba.conf. програма повинна тепер закрити."

Я спробував запустити службу, зареєстровану як локальну системну обліковий запис, а також мій власний обліковий запис (у властивостях властивостей postgres) безрезультатно. Я також спробував перезавантажити комп'ютер. Після багатьох проблем в Інтернеті, я дізнався, що добре перевірити файл pg_log. Ось зміст останнього запису pg_log:

2013-05-29 14:59:45 MDT LOG: database system був interrupted; last known up at 29.05.2013 14:58:01 MDT 2013-05-29 14:59:45 автоматична переробка в прогресі 2013-05-29 14:59:45 MDT LOG: запис з 0 length at 0/175BB98 2013-05-29 14:59:45 MDT LOG: redo is not required 2013-05-91 :45 MDT LOG: Database system ready to accept connections 2013-05-29 14:59:45 MDT LOG: autovacuum launcher started 2013-05-29 15:07:00 MDT LOG: Local connections не буде supportd by -05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013- 05-29 15:07:00 MDT LOG: локальні зв'язки не підтримуються цією будовою 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 201 -05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:09:02 active transactions 2013-05-29 15:09:03 MDT LOG: autovacuum launcher shutting down 2013-05-29 15:09:03 MDT LOG: shutting down 2013-05-29 15:09:03 MDT LOG: data shut down

Здається, що виникають проблеми з файлом pg_hba.conf, який виглядає так:

Local all all trust host all all 127.0.0.1 255.255.255.255 trust host all all 0.0.0.0 0.0.0.0 trust

Відповідно до численних пропозицій в Інтернеті я спробував змінити верхній рядок на кілька різних альтернатив (всі хости all trust/host all 127.0.0.1/32 trust/host all 192.168.0.100/24 ​​trust і т.д.). Це мало сенс для мене, оскільки у файлі журналу говорилося, що локальні з'єднання не підтримуються postgres і вказують на цей рядок. Однак жодна з моїх змін не вплинула. Я спробував перезавантажити комп'ютер після кожної зміни, але нічого не змінилося.

Коли я шукав приклади того, як виглядає файл pg_hba.conf, приклади виглядали трохи відмінними від мого файлу. Я помітив, що у файлі програми PostgreSQL на додаток до pg_hba.conf був також файл 20130529-150444-old-pg_hba.conf, який набагато більше скидався на приклади, які я знайшов в Інтернеті. Цей файл має кілька рядків коментарів до останніх кількох рядків:

# TYPE DATABASE USER ADDRESS METHOD # IPv4 локальні зв'язки: host all all 127.0.0.1/32 md5 # IPv6 локальні зв'язки: host all all::1/128 md5 # Allow replication connections from localhost, за допомогою користувача #. #host replication postgres 127.0.0.1/32 md5 #host replication postgres::1/128 md5

Я сподівався, що це був оригінальний файл pg_hba.conf, і якщо замінив новий файл вмістом старого, postgres почнуть працювати знову. Немає такої удачі. Я сподівався, що у файлі pg_log буде зареєстровано більше файлів помилок, щоб дізнатися, чи зникла раніше заявлена ​​помилка або щось змінилося, але більше файлів не було зареєстровано.

Я шукав онлайн службу протягом декількох днів, і нічого, що я знайшов, не спрацювало. Вибачте за таке довге запитання, але я хотів бути обґрунтованим і включити всю відповідну інформацію. Я був би вдячний, якби хтось міг пролити світло на цю проблему чи запропонувати пропозиції.

pg_ctl init [-s] [-D datadir] [ -o initdb-options ]

pg_ctl start [-w] [-t секунди] [ -s ] [ -D datadir] [-l ім'я файлу] [ -o параметри] [-p path] [ -c ]

pg_ctl stop [-W] [-t секунди] [ -s ] [ -D datadir] [-m s | f | i]

pg_ctl restart [-w] [-t секунди] [ -s ] [ -D datadir] [-c] [-ms | f | i] [-o параметри ]

pg_ctl reload [-s] [-D datadir ]

pg_ctl status [-D datadir ]

pg_ctl promote [-s] [-D datadir ]

pg_ctl kill signal_name process_id

pg_ctl register [-N servicename] [ -U Ім'я користувача] [-P пароль] [-D datadir] [-S a | d ] [ -w ] [ -t секунди] [ -s ] [ -o параметри ]

pg_ctl unregister [-N servicename ]

Сервер запускається як start . Процес працює у фоновому режимі, а стандартне введення зв'язується з /dev/null (або nul під керуванням Windows). За замовчуванням у Unix-подібних системах виведення та помилки сервера пишуться у пристрій стандартного виведення (не помилок) pg_ctl . Висновок pg_ctl слід перенаправити у файл або процес, наприклад, додаток ротації журналів rotatelogs; в іншому випадку, postgres буде писати висновок у керуючий термінал (у фоновому режимі) і залишиться у групі процесів оболонки. У Windows висновок та помилки сервера за замовчуванням перенаправляються до терміналу. Цю поведінку можна змінити та направити виведення сервера у файл, додавши ключ -l . Ми рекомендуємо використовувати ключ -l або перенаправляти висновок.

Для зупинки сервера використовується stop . Зупинити можна у трьох режимах, що задаються прапором -m. За замовчуванням використовується режим "Smart", який очікує завершення всіх активних клієнтських з'єднань та віддалених процесів резервування. Якщо сервер працює в режимі гарячого резервування, то відновлення та потокова реплікація буде зупинено, як тільки усі клієнтські сесії завершуватимуться. Режим "Fast" не очікує закриття клієнтських сесій та перериває віддалені процеси резервування. Усі активні транзакції відкочуються, а клієнти примусово від'єднуються, після чого сервер зупиняється. Режим "Immediate" негайно перериває всі процеси та зупиняє сервер, що призводить до наступного старту до необхідності відновлення після збою.

Для зупинки з наступним стартом сервера використовується restart. При цьому доступні прапори команди postgres. restart може не відпрацювати, якщо при старті сервера в командному рядку було вказано відносний шлях до каталогу зберігання даних.

Щоб перечитати конфігурацію (postgresql.conf, pg_hba.conf і т. д.), використовується reload, при цьому процес postgres отримує системний сигнал SIGHUP. Це дозволяє застосувати зміни без повного рестарту сервера.

Для перевірки статусу кластера використовується status . Якщо кластер запущено, буде виведено PID процесу, і навіть команда з використаними під час запуску аргументами. Якщо кластер зупинено, процес поверне статус завершення 3. Якщо не вказано каталог зберігання даних, то процес поверне статус завершення 4.

Щоб перевести резервний сервер в основний режим, використовується promote . При цьому сервер припиняє роботу в режимі відновлення та починає працювати в режимі читання-запису.

Щоб надіслати сигнал процесу, використовується kill . Це особливо застосовно в середовищі Microsoft Windows, яке не має в оснастці команди kill. Щоб переглянути список доступних сигналів, зверніться до довідки --help .

Для реєстрації в якості системної служби під керуванням Microsoft Windows використовується register. Прапор -S встановлює режим запуску служби або "auto" (на старті ОС), або "demand" (за запитом).

Щоб видалити зареєстровану службу в Microsoft Windows, використовується unregister.

Параметри

C
--core-file

На платформах, де це підтримується, сервер намагатиметься фіксувати знімки пам'яті при аваріях. Це дозволяє діагностувати та запобігати потенційним проблемам у майбутньому. -D datadir
--pgdata datadir

Вказує розміщення конфігураційних файлів кластера. Якщо не вказано, використовується значення змінного оточення PGDATA . -l ім'я файлу
--log ім'я файлу

Виводить дані журналу в filename. Файл створюється, якщо він ще немає. При цьому umask виставляється в 077, що запобігає доступу інших користувачів до цього файлу. -m режим
--mode режим

Встановлює режим зупинки кластера. modeприймає значення smart , fast , або immediate , або першою літерою кожного з доступних значень, наприклад, s . Якщо прапор опущений, використовується smart . -o параметри

Вказує прапори, які будуть передані до postgres.

Значення необхідно обрамляти одинарними або подвійними лапками, щоб гарантувати цілісність групи. -o initdb-options

Вказує прапори, які будуть передані в initdb.

Значення необхідно обрамляти одинарними або подвійними лапками, щоб гарантувати цілісність групи. -p path

Вказує розміщення програми postgres. За умовчанням використовується той самий шлях, яким знаходиться pg_ctl , або, якщо це не вдалося, то береться шлях інсталяції. Застосовувати цей параметр найчастіше немає, крім нестандартних ситуацій.

init приймає параметри аналогічно initdb. -s
--silent

Виводити лише помилки, без повідомлень інформаційного характеру. -t
--timeout

Максимальний час (в секундах) очікування запуску або зупинки сервера. За промовчанням це 60 секунд. -V
--version

Виводить версію pg_ctl і перериває виконання. -w

Очікує завершення запуску або зупинки. Це режим за замовчуванням для операцій зупинки, але не запуску. На етапі запуску pg_ctl постійно намагається підключитися до сервера. На етапі зупинки pg_ctl перевіряє наявність файлу PID. Цей параметр дозволяє встановити контрольне слово для SSL на старті сервера. pg_ctl повертає код завершення, виходячи з операцій запуску чи зупинки. -W

Ігнорувати очікування завершення запуску або зупинки сервера. Ця поведінка використовується за замовчуванням для режимів запуску та повторного запуску. -?
--help

Вивести довідку за командою pg_ctl та перервати виконання.

Параметри, специфічні для Windows

N servicename

Ім'я системної служби, що реєструється. Воно використовується як системне і відображуване значення. -P пароль

Пароль користувача, який стартує службу. -S тип запуску

Тип запуску системної служби. Може приймати значення: auto або demand, або бути представлений першою літерою назви кожного наведеного значення. За замовчуванням використовується auto. -U Ім'я користувача

Ім'я користувача, від імені якого буде запущено службу. Для доменних користувачів необхідно використовувати нотацію DOMAIN\username.

Запитання: Не стартує служба PostgreSQL

Windows Server 2012
PostgreSQL Database Server 9.4.2-1.1C(x64)
На сервері з середини квітня крутилися 2 бази 1С
Файл postgresql.conf був відредагований за рекомендаціями з сайту 1с за параметрами сервера.

За словами адміна, вчора штатно вимкнули, потім увімкнули.
Служба не стартує, у логах ось що:

2016-05-06 10:05:40 GMT LOG: database system був interrupted; last known up at 2016-05-06 09:59:33 GMT
2016-05-06 10:05:40 GMT LOG: database system не був propert shut down; автоматичний перехід в прогрес
2016-05-06 10:05:40 GMT LOG: record with zero length at 6/C7F6AAA8
2016-05-06 10:05:40 GMT LOG: redo is not required
2016-05-06 10:05:40 GMT FATAL: не можна користуватися статусом трансакції 1262199
2016-05-06 10:05:40 GMT Детальний опис: Немає файлу "pg_clog/0001": Немає такого файлу або directory.
2016-05-06 10:05:40 GMT LOG: startup process (PID 24696) exited with exit code 1
2016-05-06 10:05:40 GMT

Служба працює під користувачем USR1CV8, права у нього на папку Data повні
Архіви є тижневою давністю.

Відповідь:

тоді бази у вас нема.

--
Maxim Boguk

Запитання: postgresql - після перенесення каталогу data служба не запускається

Добрий час доби. Є вищезгадана СУБД, каталог даних встановлений шляхом: /var/lib/pgsql/9.3/data
Потрібно перенести каталог даних у розташування /postgre_dbs/data. Мої дії:
1. Зупиняю PostGreSQL
2. Копіюю папку data з усіма підпапками, та записами прав на папки та файли (cp -p -R) у /postgre_dbs
3. У файлі /var/lib/pgsql/9.3/data пишу рядок:
data_directory = "/postgre_dbs/data/"
4. Пробую запустити службу postgresql – отримую FAILED
5. дивлюся pgstartup.log – там рядки:
< 2015-10-20 21:14:17.361 ALMT >ВАЖЛИВО: файл блокування "postmaster.pid" вже існує
< 2015-10-20 21:14:17.361 ALMT >ПІДКАЗКА: Інший екземпляр postmaster (PID 1633) працює з каталогом даних "/postgre_dbs/data"?

У чому причина проблеми, як її вирішити?

Відповідь: guestfreeman,

Ви йдете чітко за планом досвідчених товаришів:

Як запускається служба PostgreSQL?
Чи вона знає, що БД знаходиться в іншому каталозі?

Запитання: Не стартує служба postgree

2016-04-27 13:28:46 IRKT LOG: database system був interrupted; last known up at 2016-04-27 13:16:51 IRKT
2016-04-27 13:28:46 IRKT LOG: invalid primary checkpoint record
2016-04-27 13:28:46 IRKT LOG: вільний секційний вік checkpoint link in control file
2016-04-27 13:28:46 IRKT PANIC.
2016-04-27 13:28:46 IRKT LOG: startup process (PID 8912) exited with exit code 3
2016-04-27 13:28:46 IRKT LOG: aborting startup due to startup process failure

З пошуків в інтернеті спробував виконати pg_controldata

PostgreSQL\9.4.2-1.1C\bin>pg_controldata e:\pql

pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6254454928233336196
Database cluster state: in production
pg_control last modified: 27.04.2016 9:04:41
Докладніше checkpoint location: DC/223641B8
Prior checkpoint location: DC/1F301DA8
Докладніше checkpoint"s REDO location: DC/213D1950
Докладніше checkpoint"s REDO WAL file: 00000001000000DC00000021
Останній checkpoint's TimeLineID: 1
Останній checkpoint"s PrevTimeLineID: 1
Останній checkpoint"s full_page_writes: on
Останній checkpoint"s NextXID: 0/2148384
Останній checkpoint"s NextOID: 4123902
Останній checkpoint"s NextMultiXactId: 1
Останній checkpoint"s NextMultiOffset: 0
Останній checkpoint's oldestXID: 668
Останній checkpoint's oldestXID's DB: 1
Останній checkpoint's oldestActiveXID: 0
Останній checkpoint's oldestMultiXid: 1
Останній checkpoint"s oldestMulti"s DB: 16402
Time of latest checkpoint: 27.04.2016 9:04:31
Fake LSN counter для unlogged rels: 0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
Current wal_level setting: minimal
Current wal_log_hints setting: off
Current max_connections setting: 200
Current max_worker_processes setting: 8
Current max_prepared_xacts setting: 0
Current max_locks_per_xact setting: 64
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in index: 32
Maximum size of a TOAST chunk: 1996
Кількість великого об'єкта chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by reference
Data page checksum version: 0

PostgreSQL\9.4.2-1.1C\bin>pg_resetxlog -o 4123902 -x 2148384 -f e:\pql
pg_resetxlog: could not create pg_control file: File exists

Як вирішити проблему з pg_resetxlog: could not create file: File exists?

Відповідь:

Спробуйте додати ключ
-P disable system indexes
(але швидше за все у вас не лише цей індекс злетів).

Якщо у вас немає репліки ні backup - я б сказав що шансів відновити базу у вас близько 0.
Відновити так, щоб 1C заробив - ще менше.

PS: а як ви такого досягли і яке значення fsync було в конфізі?

--
Maxim Boguk

Питання: portable postgresql doesn"t listen

Запуск портативного postgre.
Каталог - копія працюючого postgresql 9.3
ОС - Windows 7
На комп'ютері був встановлений сервер postgresql 9.3, але в момент запуску poratble postgresql процес був зупинений, процеси postgress в диспетчері завдань windows завершені

Для запуску до каталогу postgresql доданий командний файл:
ECHO ON for %%i in (*.bat) SET CD=%%~dpi REM Встановлюємо змінні оточення для запуску PostgreSQL SET PATH="%CD%bin" ;%PATH% SET PGDATA=%CD%data SET PGDATABASE= postgres SET PGUSER=postgres SET PGPORT=5439 SET PGLOCALEDIR=%CD%share \locale REM%CD%bin\initdb CD%\bin\pg_ctl -D%CD%data stop

Сервер стартує. Видаються повідомлення:
... F:\Temp\9.3 \bin\pg_ctl -D F:\Temp\9.3 \data -l logfile start Сервер запускається ECHO "Press Enter to Stop PostgreSQL Server" pause

Намагаюся підключитися до сервера з pgAdmin III
Властивості підключення:
Ім'я: TempPostgre Хост: localhost Служба: порожній рядок Обслуговування DB: postgres Ім'я користувача:postgres Пароль:X (Той, який був для бази-прототипу)

Отримую повідомлення:
Server doesn"t listen
The server doesn't accept conections: connections library reports

При підключенні до сервера пробував на адресу хоста: 10.10.10.121 (ip комп'ютера в локальної мережі). Результат той самий.

Відповідь:Проблема була у файлі postgresql.conf, який знаходиться у каталозі даних
Після встановлення у цьому файлі
port = 5439 # (change requires restart)

все запрацювало.

Всім дякую

Питання: помилка 1053 під час запуску postgresql

заздалегідь перепрошую, якщо тема створена не в тому розділі.

win10 x64
postgresql 8.4

автоматично служба не запускається. якщо примусово - вилазить помилка 1053:

антивірус нод32. брандмауер відключив (хоча служба була у винятках):

зараз вона у винятках брандмауера віндовс:

Postgresql використовую для роботи holdemmanager2. Тому через не запуск postgresql не запускається і holdemmanager2.
Допоможіть будь ласка. перелопатив уже півмережі – нічого не допомагає.

Відповідь:

при цьому в службах постгрі не в статусі "running"

Запитання: Реплікація даних PostgreSQL - Windows Server 2008

Є сервер БД, з яким працюють клієнти, та резервний сервер, на який треба налаштувати реплікацію з основної бази даних.
У моєму випадку використовується PostgreSQL 9.2.1, який встановлений на обох серверах

зробив за цією інструкцією не працює

при налаштуванні конфігураційних файлів (як зазначено у статті) та при додаванні файлу recovery.conf база перестає стартувати.

Потрібна ваша допомога.

Відповідь: askat123,

якщо база не стартує – у логах обов'язково буде написано чому. потрібно починати з них, перш ніж гадати.

Запитання: Postgresql 9.5 не запускається автоматично після збою живлення

Добридень!
Допоможіть, будь ласка, розібратися з наступною проблемою:
На десктопі під Debian 8.2 встановлена ​​тестова база даних PostgreSQL (9.5.3). Налаштування БД у postgresql.conf – мінімальні – listen_adress, port тощо. Решта за замовчуванням. Файл додаю.
Досить часто вимикають електроенергію, упсу немає.

Після появи харчування СУБД сама не запускається – лог наводжу нижче

автор

2016-08-04 19:13:30 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:30 MSK ПОВІДОМЛЕННЯ: робота системи БД була перервана; останній момент роботи: 2016-08-04 16:15:49 MSK 2016-08-04 19:13:30 MSK [н/д]@[н/д] ПОВІДОМЛЕННЯ: неповний стартовий пакет 2016-08-04 19:13:31 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:31 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:32 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:32 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:33 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:33 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:34 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:34 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:35 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:35 MSK [email protected]ВАЖЛИВО: система баз даних запускається 2016-08-04 19:13:45 MSK ПОВІДОМЛЕННЯ: система БД була зупинена позаштатно; проводиться автоматичне відновлення 2016-08-04 19:13:45 MSK ПОВІДОМЛЕННЯ: неправильна довжина запису зі зміщення 1/9F46638 2016-08-04 19:13:45 MSK ПОВІДОМЛЕННЯ: дані REDO не потрібні 2016-08-04 19:13:46 MSK ПОВІДОМЛЕННЯ: Захист від накладання мультитранзакцій зараз включений 2016-08-04 19:13:46 MSK ПОВІДОМЛЕННЯ: вимкнення 2016-08-04 19:13:46 MSK ПОВІДОМЛЕННЯ: система БД вимкнена

Після цього або запуском вручну або після перезавантаження комп'ютера система стартує нормально.
Як можна забезпечити, щоб після позаштатного вимкнення у разі успішного відновлення система запускалася автоматично?

До повідомлення додано файл ( postgresql.conf- 21Kb)

Відповідь: asdasd1,

я підозрюю, що налаштування systemd винні. після якогось таймууту він вимикає базу штатно:

2016-08-04 19:13:35 MSK ПОВІДОМЛЕННЯ: отримано запит на "ввічливе" виключення

перегляньте, які налаштування в /usr/lib/systemd/system/postgresql-9.5.service файлі.

Запитання: Не стартує PostgreSQL

Добридень
Випав Postgresql і більше не запускається, у логах

автор

LOG: could not link file "pg_xlog/xlogtemp.79221" to "pg_xlog/00000001000000000000004F" (initialization of log file 0, segment 79): Operation not permitted LOG: startup process (PID 79221) exited with exit code 1 LOG: aborting startup due to startup process failure LOG: loaded library "online_analyze" LOG: loaded library "plantuner" LOG: database system був shut down at 2015-04-09 09:11:44 EEST LOG: could not link file "pg_xlog/xlogtemp.79344" to "pg_xlog/00000001000000000000004F" (initialization of log file 0, segment 79): Operation not permitted FATAL: не можна відкрити файл "pg_xlog/00000001000000000000004F" (log file 0, segment 79): No such file or directory LOG: startup process (PID 79344) exited with exit code 1 LOG: aborting startup due to startup process failure

Зайшов в цю папку і дійсно немає файлу 00000001000000000000004F.

Не можу зрозуміти, чому так вийшло. Працювало, а потім хлоп і все не працює.

Як вирішити цю проблему, як запустити Постгрес?

Відповідь: Dark Smoke,

Найбільш підозріло виглядає:

автор
"LOG: could not link file "pg_xlog/xlogtemp.79344" to "pg_xlog/00000001000000000000004F" (initialization of log file 0, segment 79): Operation not permitted"

Зазвичай це сліди втручання поганого антивірусу в роботу бази (або з правами у вас щось не так стало але саме собі не так з правами не стає).
Директорія бази має бути виключена зі списку місць, куди антивірус може заходити.

Питання: Автозапуск PostgreSQL 9.6 у Debian 8

Вітаю вас!
Зіткнувся з проблемою старту PostgreSQL 9.6 під час завантаження ОС Debian 8.
Автозапуск намагаюся зробити власним скриптом написаним відповідно до офіційної документації щодо СУБД (пп. 18.3 Запуск сервера БД, стор. 565)

Вміст файлу \etc\init.d\postgresql:
#!/bin/sh -e ### BEGIN INIT INFO # Provides: postgresql # Required-Start: $local_fs $remote_fs $network $time # Required-Stop: $local_fs $remote_fs $network $time# Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: PostgreSQL RDBMS server### END INIT INFO PG_PATH="/usr/lib/postgresql/9.6/bin" PGDATA= PATH=/bin:/usr/bin:/sbin:/usr/sbin DESC="postgresql daemon" NAME=postgresql DAEMON= /usr/lib/postgresql/9.6 /bin/postgresql PIDFILE="$PGDATA/postmaster.pid" SCRIPTNAME=/etc/init.d/"$NAME" case "$1" in start) su - postgres -c "$PG_PATH /pg_ctl start -D $PGDATA -l $PGDATA/log_file.txt" exit 0;; stop|status) su - postgres -c "$PG_PATH/pg_ctl $1";; kill) su - postgres -c "$PG_PATH/pg_ctl stop-m fast";; reboot) $0 kill $0 start;; *) echo "Використовуйте: $0 (start|stop|kill|reboot|status)" exit 1;; esac exit 0
Під час запуску з консолі скрипт працює коректно
[email protected]:~# /etc/init.d/postgresql startсервер запускається [email protected]:~# /etc/init.d/postgresql status pg_ctl: сервер працює (PID: 759 ) /usr/lib/postgresql/9.6 /bin/postgres "-D" "/var/lib/postgresql/9.6/main" [email protected]:~# /etc/init.d/postgresql stop очікування завершення роботи сервера.... готово сервер зупинено [email protected]:~#
На скрипт є посилання на:
/etc/rc0.d -> K02postgresql
/etc/rc1.d -> K02postgresql
/etc/rc2.d -> S02postgresql
/etc/rc3.d -> S02postgresql
/etc/rc4.d -> S02postgresql
/etc/rc5.d -> S02postgresql
/etc/rc6.d -> K02postgresql

Намагався розібратися зі стандартним скриптом автозапуску PostgeSQL, але не подужав.
Тим більше, що в мануалі за postgresql рекомендується робити саме так.
Вже зневірився шукати відповідь в Інеті. Прошу конкретної поради.

Відповідь:Дякую Йош!
Пощастило, натрапив на гарну статтю на Хабрахабрі

За нею:
1. У /etc/systemd/system/multi-user.target.wants знайшов посилання на unit postgresql.service
2. Переписав його так
Description=PostgreSQL RDBMS Type=forking PIDFile=/var/lib/postgresql/9.6 /main/postmaster.pid WorkingDirectory=/usr/lib/postgresql/9.6 /bin User=postgres Group=postgres Environment=PGDATA=/var/lib/ postgresql/9.6 /main OOMScoreAdjust=-100 ExecStart=/usr/lib/postgresql/9.6 /bin/pg_ctl start -D /var/lib/postgresql/9.6/main -l /var/lib/postgresql/9.6/main/log_file .txt ExecStop=/usr/lib/postgresql/9.6 /bin/pg_ctl stop -m fast ExecReload=/usr/lib/postgresql/9.6 /bin/pg_ctl restart -D /var/lib/postgresql/9.6/main TimeoutSec=60 #Restart=always #ExecStart=/bin/true #ExecReload=/bin/true #RemainAfterExit=on WantedBy=multi-user.target

До речі, тут використовується рішення, яке дозволяє перешкоджати агресивній роботі OOM killer, про яку пишеться в мануалі по postgres. Про нього йдеться, що його неможливо зупинити, але виявляється, що це можливо, вказавши OOMScoreAdjust=-1000
OOM killer – механізм знищення процесів при нестачі пам'яті, який був реалізований на рівні ядра, починаючи з Linux 2.6 та новіше.

Ще можна прокоментувати рядок #Restart = always.
У такому разі буде відстежуватися наявність зазначеного PIDFile і за його відсутності робитися спроба запуску postgresql
Можна вважати це аналогом скрипту з мого попереднього посту, але з реалізацією на рівні системи))

Після зміни unit-файлу postgresql.service по черзі виконав команди для переустановки та перевірки його роботи
systemctl disable postgresql.service systemctl enable postgresql.service systemctl -l status postgresql.service systemctl start postgresql.service systemctl stop postgresql.service

При вимкненні системи сервер коректно зупиняється і при старті операційної системи Debian 8 автоматично завантажується.
Прибрав милицю, яку робив для Cron

Якщо є недоліки у запропонованому рішенні з радістю вислухаю.

Питання: При установці Postgresql 9.4 у Debian 8 (jessie) не створюється директорія /etc/postgresql

Добридень!

Було встановлено Postgresql 9.4. ОС Debian 8 (jessie)
У черговий момент горе адміністратор вирішив перевстановити його.
При цьому, при видаленні пакетів Postgresql і Pgadmin3 видаляв щось вручну.

В результаті на сьогоднішній день адміну немає, а при моїх усіляких спробах встановити Postgresql не створюється директорія /etc/postgresql і відповідно конфігураційні файли, які в ній зберігаються.

Підкажіть будь ласка якомога тепер коректно встановити Postgresql-сервер.

Використання стандартних методів sudo apt-get --purge remove postgresql та подальше встановлення sudo apt-get install postgresql не допомагає...

Заздалегідь дякую за відповіді!

Відповідь:
Встановлював так.

Після видалення postgresql-common з параметром --purge та повторної установки всі конфіги були відновлені.
Прописав користувачів, поправив налаштування та все запрацювало!
Велике дякую!!!

Це повідомлення призначене насамперед мені особисто і нашої служби підтримки, т.к. проблема подібна до описаної нижче відбувається із завидною періодичністю і потрібно пам'ятати основні кроки з її вирішення.

Отже, історія починається з того, що мені 30 грудня об 11-30 дзвонять із повідомленням про те, що в одного з наших клієнтів не запускається наша система, оскільки не може підключитися до бази даних (як СУБД у нас використовується PostgreSql версії 8.1) . Люди пояснюють це тим, що годину тому вирубало світло та комп'ютер вирубався некоректно, а після включення – все перестало працювати:)

Хороші користувачі нашої системи знають, де знаходиться кнопка пуск і знають, що в системі не дві годинки "одні з цифрами, а інші пісочні". Тому єдине, що вдалося зробити по телефону, то спробувати руками запустити службу СУБД, результат – служба таки не запускається. Довелося прокидати на той комп'ютер інтернет (на комп'ютерах, де встановлена ​​наша система інтернету бути не повинно) для можливості віддаленого підключення.

Після підключення до віддаленому комп'ютеруя спробував запустити службу і отримав таке повідомлення: “Служба PostgreSql Database Server 8.1” на “Локальний комп'ютер” була запущена і потім зупинена. Деякі служби автоматично зупиняються, якщо їм нема чого робити, наприклад, служба журналів та оповіщень продуктивності”. Мда…

Проблема в тому, що на той момент це була єдина доступна інформація… Логи PostgreSql порожні, записів у них ніяких, у системних логах теж порожнеча.

Налагодження служб – процес не простий, тому багато розробників передбачають механізми запуску програми-служби як звичайної консольної програми за допомогою ключів командного рядка. І PostgreSql у цьому плані – не виняток; Для запуску потрібно використовувати наступну команду (Hint: цю команду можна запустити тільки з-під неадміністративного користувача системи, правда, якщо ви про це забудете, PostgreSql дуже швидко вам про це нагадає):

postgres -D " "

Запускаємо і дивимося на повідомлення про помилку. У моєму випадку це повідомлення звучало приблизно так:

FATAL - bogus data in lock file "postmaster.pid"

Безумовно, мені пощастило, проблема виправилася. Чомусь вказаний файл виявився порожнім, і мені знадобилося скопіювати його вміст з робочого екземпляра СУБД, що не склало особливих труднощів.

Мораль цього повідомлення в тому, що якщо база лягла, або сталися якісь інші проблеми з системою, то перш ніж встановлювати заново СУБД (або систему повністю) і втрачати при цьому всі дані, потрібно хоча б спробувати з'ясувати в чому проблема, можливо, є всі шанси, що вам вдасться відновити працездатність не такими радикальними методами.

З.И. Всіх з наступаючим Новим Роком та побажання того, щоб ваші системи були стабільними та надійними і не псували ваш сон, але навіть якщо якісь проблеми і виникали, то у вас завжди були напоготові варіанти, як із цією ситуацією впоратися.

Це повідомлення призначене насамперед мені особисто і нашої служби підтримки, т.к. проблема подібна до описаної нижче відбувається із завидною періодичністю і потрібно пам'ятати основні кроки з її вирішення.

Отже, історія починається з того, що мені 30 грудня об 11-30 дзвонять із повідомленням про те, що в одного з наших клієнтів не запускається наша система, оскільки не може підключитися до бази даних (як СУБД у нас використовується PostgreSql версії 8.1) . Люди пояснюють це тим, що годину тому вирубало світло та комп'ютер вирубався некоректно, а після включення – все перестало працювати:)

Хороші користувачі нашої системи знають, де знаходиться кнопка пуск і знають, що в системі не дві годинки "одні з цифрами, а інші пісочні". Тому єдине, що вдалося зробити по телефону, то спробувати руками запустити службу СУБД, результат – служба таки не запускається. Довелося прокидати на той комп'ютер інтернет (на комп'ютерах, де встановлена ​​наша система інтернету не повинно бути) для можливості віддаленого підключення.

Після підключення до віддаленого комп'ютера я спробував запустити службу та отримав таке повідомлення: “Служба PostgreSql Database Server 8.1” на “Локальний комп'ютер” була запущена і потім зупинена. Деякі служби автоматично зупиняються, якщо їм нема чого робити, наприклад, служба журналів та оповіщень продуктивності”. Мда…

Проблема в тому, що на той момент це була єдина доступна інформація… Логи PostgreSql порожні, записів у них ніяких, у системних логах теж порожнеча.

Налагодження служб – процес не простий, тому багато розробників передбачають механізми запуску програми-служби як звичайної консольної програми за допомогою ключів командного рядка. І PostgreSql у цьому плані – не виняток; Для запуску потрібно використовувати наступну команду (Hint: цю команду можна запустити тільки з-під неадміністративного користувача системи, правда, якщо ви про це забудете, PostgreSql дуже швидко вам про це нагадає):

postgres -D " "

Запускаємо і дивимося на повідомлення про помилку. У моєму випадку це повідомлення звучало приблизно так:

FATAL - bogus data in lock file "postmaster.pid"

Безумовно, мені пощастило, проблема виправилася. Чомусь вказаний файл виявився порожнім, і мені знадобилося скопіювати його вміст з робочого екземпляра СУБД, що не склало особливих труднощів.

Мораль цього повідомлення в тому, що якщо база лягла, або сталися якісь інші проблеми з системою, то перш ніж встановлювати заново СУБД (або систему повністю) і втрачати при цьому всі дані, потрібно хоча б спробувати з'ясувати в чому проблема, можливо, є всі шанси, що вам вдасться відновити працездатність не такими радикальними методами.

З.И. Всіх з наступаючим Новим Роком та побажання того, щоб ваші системи були стабільними та надійними і не псували ваш сон, але навіть якщо якісь проблеми і виникали, то у вас завжди були напоготові варіанти, як із цією ситуацією впоратися.