systemctl status failed-et jelez, miután a Postgres-t pg_ctl-lel restartoltam

 ( FLYer | 2015. október 28., szerda - 15:15 )

Sziasztok!

PostgreSQL-el ismerkedem, ezért egy CentOS 7.1-re repo-ból felraktam a 9.4-es verziót. (Az itteni leírás szerint: https://wiki.postgresql.org/wiki/YUM_Installation)
Minden szép és jó, csak egy érdekességre lettem figyelmes a postgres service leállításával/elindításával kapcsolatban.

A start/stop megy a pg_ctl segítségével (pg_ctl stop -m fast; pg_ctl start) illetve systemctl-el is (systemctl stop postgresql-9.4.service; systemctl start postgresql-9.4.service).

Ami érdekes a systemctl status postgresql-9.4.service kimenete, ha pg_ctl-el újra lett indítva a DB:

# systemctl status postgresql-9.4.service
postgresql-9.4.service - PostgreSQL 9.4 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.4.service; enabled)
Active: failed (Result: exit-code) since sze 2015-10-28 14:00:48 CET; 2s ago
Process: 3770 ExecStop=/usr/pgsql-9.4/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=1/FAILURE)
Process: 3754 ExecStart=/usr/pgsql-9.4/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 (code=exited, status=0/SUCCESS)
Process: 3749 ExecStartPre=/usr/pgsql-9.4/bin/postgresql94-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 3759 (code=exited, status=0/SUCCESS)

okt 28 14:00:37 postgresql-test systemd[1]: Starting PostgreSQL 9.4 database server...
okt 28 14:00:37 postgresql-test pg_ctl[3754]: < 2015-10-28 14:00:37.266 CET >LOG: redirecting log output to logging collector process
okt 28 14:00:37 postgresql-test pg_ctl[3754]: < 2015-10-28 14:00:37.266 CET >HINT: Future log output will appear in directory "pg_log".
okt 28 14:00:38 postgresql-test systemd[1]: Started PostgreSQL 9.4 database server.
okt 28 14:00:48 postgresql-test pg_ctl[3770]: pg_ctl: PID file "/var/lib/pgsql/9.4/data/postmaster.pid" does not exist
okt 28 14:00:48 postgresql-test pg_ctl[3770]: Is server running?
okt 28 14:00:48 postgresql-test systemd[1]: postgresql-9.4.service: control process exited, code=exited status=1
okt 28 14:00:48 postgresql-test systemd[1]: Unit postgresql-9.4.service entered failed state.

Azt értem, hogy ha a systemd-t megkerülve birizgáltam a service-t és megváltozott a PID-je, ezért failed a státusz.
De van arra valami megoldás, hogy a systemd-nél kikényszerítsem, hogy az új PID-del futó postgres-t nézze?

Ami megoldást erre találtam az az, hogy pg_ctl stop segítségével megállítom a DB-t, majd systemctl start-tal elindítom, utána active (running) státuszú, amíg a pg_ctl-el megint hozzá nem nyúlok.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem igazan latom ertelmet annak, amit szeretnel, hatarozottan nem a systemd feladata, hogy kitalalja, ki es hogyan inditgat programokat. Ha mindenaron a pg_ctl-lel akarod birizgalni, akkor tedd disabled allapotba, es a systemd nem fog foglalkozni vele.

Most mondjam, hogy bezzegasysvinit :-P Nem mondom, csak gondolom :-P

Szerintem systemctl-lel kellene újraindítanod. Egyébként van egy olyan érzésem, ha nem systemctl-lel indítod, más SELinux kontextusban történik az indítás, így agyoncsaptad a biztonságot is szerintem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

okt 28 14:00:48 postgresql-test pg_ctl[3770]: pg_ctl: PID file "/var/lib/pgsql/9.4/data/postmaster.pid" does not exist

Ha jól látom mikor nem systemctl-el indítod a pid file nem a fent említett helyre generálódik ergo nem tudja eldönteni hogy mi is van. vagy ilyenkor joga nincs a fájlhoz?

Megoldas: systemctl stop postgresql-9.4.service

Btw, szervizeknel nem kell a .service kiterjesztest hozzairni, automatikusan tudja, h mirol van szo.
--
Blog | @hron84
Üzemeltető macik

Annyival kiegészítem, hogy ha azt akarja, hogy ne induljon el boot-kor, akkor kell egy

systemctl disable postgresql-9.4

is, de ha az is kell, hogy más se tudja elindítani, akkor pedig egy

systemctl mask postgresql-9.4

a helyes eljárás. De szerintem ez nem szép, mert elszúrja mindazt, amit a SELinux nyújt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Partially, illetve mintha a systemctl tudna respawnot is, bar ezt csak hallottam valahol. De szvsz egyebkent is szebb systemctl-lel tolni, meg ha nem is vagyok systemd fan (oke, _nagyon_ nem vagyok az, hozzatok vissza az upstartot).
--
Blog | @hron84
Üzemeltető macik

off

Nézd, nyilván van hátránya, magam is jobban szeretem azokat az eszközöket, amelyek faék egyszerűségűek, átláthatóak, hackelhetők. A systemd konfigurációja szép, a szolgáltatásai vonzók, működik is, de valóban rossz érzés, hogy ha véletlenül valami nem jó benne, ott kő kövön nem marad.

Fedorát használok, ebben jelent meg talán 4.5 évvel ezelőtt a systemd, így igen régóta használom. Nem nagyon birizgálom, viszont megy a gépem, nem szokott baj lenni vele. Értem én, hogy ez egy otthoni desktop gép, nem pedig egy sok CPU-s szerver, de nem gondolom a systemd-t annyira rossznak, mint amennyire félnek tőle néhányan.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem a bugokkal van a bajom, hanem hogy ha nekem nem felel meg a rendszer sajat intelligenciaja, nem tudok hozzaadni masfajtat.

Pl, upstartban nem volt kotelezo _egy_ binarist inditani, siman lehetett egy komplett logika az inditocuccban, ami a vegen elinditott _egy_ binarist. Most ezt kulon ki kell szervezni scripbe, es azt behuzni, semennyivel se jobb megoldas, de legalabb bonyolitja a deploymentet.

--
Blog | @hron84
Üzemeltető macik

A systemd-ben van függőség kezelés, így aztán szerintem mindegyik binárishoz tartozhat külön konfig, csak függenek egymástól.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE