Re: [PATCH] better systemd integration - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [PATCH] better systemd integration
Date
Msg-id CAFj8pRA4=hVj-d=8O7PSMjopsFUHPcAftd5tLqFC_xb035hNQA@mail.gmail.com
Whole thread Raw
In response to [PATCH] better systemd integration  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] better systemd integration  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Hi

2015-11-17 15:08 GMT+01:00 Peter Eisentraut <peter_e@gmx.net>:
I have written a couple of patches to improve the integration of the
postgres daemon with systemd.

The setup that is shipped with Red Hat- and Debian-family packages at
the moment is just an imitation of the old shell scripts, relying on
polling by pg_ctl for readiness, with various custom pieces of
complexity for handling custom port numbers and such.

In the first patch, my proposal is to use sd_notify() calls from
libsystemd to notify the systemd daemon directly when startup is
completed.  This is the recommended low-overhead solution that is now
being adopted by many other server packages.  It allows us to cut out
pg_ctl completely from the startup configuration and makes the startup
configuration manageable by non-wizards.  An example is included in the
patch.

The second patch improves integration with the system journal managed by
systemd.  This is a facility that captures a daemon's standard output
and error and records it in configurable places, including syslog.  The
patch adds a new log_destination that is like stderr but marks up the
output so that systemd knows the severity.  With that in place, users
can choose to do away with the postgres log file management and let
systemd do it.

The third patch is technically unrelated but arose while I was working
on this.  It improves error reporting when the data directory is missing.


2. all tests passed

The issues:

1. configure missing systemd integration test, compilation fails:

postmaster.o postmaster.c
postmaster.c:91:31: fatal error: systemd/sd-daemon.h: No such file or directory

3. PostgreSQL is able to write to systemd log, but multiline entry was stored with different priorities

 do $$ begin raise warning 'NAZDAREK****'; end $$;

first line

{
    "__CURSOR" : "s=cac797bc03f242febea9f32357bba773;i=b4a5;b=e8d5b3df2ebf46dd86c39046b326bd32;m=1cb792a63b;t=52a4f3ad40860;x=57014959bf6e3481",
    "__REALTIME_TIMESTAMP" : "1453894661310560",
    "__MONOTONIC_TIMESTAMP" : "123338925627",
    "_BOOT_ID" : "e8d5b3df2ebf46dd86c39046b326bd32",
    "SYSLOG_FACILITY" : "3",
    "_UID" : "1001",
    "_GID" : "1001",
    "_CAP_EFFECTIVE" : "0",
    "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0",
    "_MACHINE_ID" : "b8299a722638414a8776d3e130e228e4",
    "_HOSTNAME" : "localhost.localdomain",
    "_SYSTEMD_SLICE" : "system.slice",
    "_TRANSPORT" : "stdout",
    "SYSLOG_IDENTIFIER" : "postgres",
    "_PID" : "3150",
    "_COMM" : "postgres",
    "_EXE" : "/usr/local/pgsql/bin/postgres",
    "_CMDLINE" : "/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data -c log_destination=systemd",
    "_SYSTEMD_CGROUP" : "/system.slice/postgresql.service",
    "_SYSTEMD_UNIT" : "postgresql.service",
    "PRIORITY" : "5",
    "MESSAGE" : "WARNING:  NAZDAREK****"
}

second line

{
    "__CURSOR" : "s=cac797bc03f242febea9f32357bba773;i=b4a6;b=e8d5b3df2ebf46dd86c39046b326bd32;m=1cb792a882;t=52a4f3ad40aa6;x=ae9801b2ecbd4da3",
    "__REALTIME_TIMESTAMP" : "1453894661311142",
    "__MONOTONIC_TIMESTAMP" : "123338926210",
    "_BOOT_ID" : "e8d5b3df2ebf46dd86c39046b326bd32",
    "PRIORITY" : "6",
    "SYSLOG_FACILITY" : "3",
    "_UID" : "1001",
    "_GID" : "1001",
    "_CAP_EFFECTIVE" : "0",
    "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0",
    "_MACHINE_ID" : "b8299a722638414a8776d3e130e228e4",
    "_HOSTNAME" : "localhost.localdomain",
    "_SYSTEMD_SLICE" : "system.slice",
    "_TRANSPORT" : "stdout",
    "SYSLOG_IDENTIFIER" : "postgres",
    "_PID" : "3150",
    "_COMM" : "postgres",
    "_EXE" : "/usr/local/pgsql/bin/postgres",
    "_CMDLINE" : "/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data -c log_destination=systemd",
    "_SYSTEMD_CGROUP" : "/system.slice/postgresql.service",
    "_SYSTEMD_UNIT" : "postgresql.service",
    "MESSAGE" : "CONTEXT:  PL/pgSQL function inline_code_block line 1 at RAISE"
}

Is it expected?

Second issue:

Mapping of levels between pg and journal levels is moved by1

+            case DEBUG1:
+                systemd_log_prefix = "<7>" /* SD_DEBUG */;
+                break;
+            case LOG:
+            case COMMERROR:
+            case INFO:
+                systemd_log_prefix = "<6>" /* SD_INFO */;
+                break;
+            case NOTICE:
+            case WARNING:
+                systemd_log_prefix = "<5>" /* SD_NOTICE */;
+                break;
+            case ERROR:
+                systemd_log_prefix = "<4>" /* SD_WARNING */;
+                break;
+            case FATAL:
+                systemd_log_prefix = "<3>" /* SD_ERR */;
+                break;
+            case PANIC:

is it expected?

This is little bit unexpected - (can be correct).

When I use filtering "warnings", then I got errors, etc. I can understand so these systems are not compatible, but these differences should be well documented.

I didn't find any other issues. It is working without any problems.

Regards

Pavel

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Next
From: Rushabh Lathia
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW