Re: [PATCH] better systemd integration

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] better systemd integration
Date: 2016-01-27 12:02:25
Message-ID: CAFj8pRA4=hVj-d=8O7PSMjopsFUHPcAftd5tLqFC_xb035hNQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

2015-11-17 15:08 GMT+01:00 Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rushabh Lathia 2016-01-27 12:23:36 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Aleksander Alekseev 2016-01-27 11:45:42 Re: Patch: fix lock contention for HASHHDR.mutex