RE: Postgres 10.7 Systemd Startup Issue

Thanks for reaching out Francisco.  Here's some relevant information related to your questions.

Here's the service we're running (removed superfluous stuff like comments):

[Unit]
Description=PostgreSQL 10 database server
Documentation=https://www.postgresql.org/docs/10/static/
After=syslog.target
After=network.target

[Service]
Type=forking
User=postgresdbad
Group=postgresdba
Environment=PGDATA=/hostname/pg/pgdba1dbal/data
OOMScoreAdjust=-1000
Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
Environment=PG_OOM_ADJUST_VALUE=0
ExecStart=/hostname/pg/PostgreSQL-10.7/bin/postgres -D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=0

[Install]
WantedBy=multi-user.target



Here's the actual status:

● postgres.service - PostgreSQL 10 database server
   Loaded: loaded (/etc/systemd/system/postgres.service; enabled; vendor preset: disabled)
   Active: activating (start) since Thu 2019-06-06 14:00:39 EDT; 23s ago
     Docs: https://www.postgresql.org/docs/10/static/
 Main PID: 4094 (code=exited, status=2);         : 4382 (postgres)
    Tasks: 9
   CGroup: /system.slice/postgres.service
           ├─4382 /hostname/pg/PostgreSQL-10.7/bin/postgres -D /hostname/pg/postgres/data
           ├─4385 postgres: logger process
           ├─4387 postgres: checkpointer process
           ├─4388 postgres: writer process
           ├─4389 postgres: wal writer process
           ├─4390 postgres: autovacuum launcher process
           ├─4391 postgres: archiver process
           ├─4392 postgres: stats collector process
           └─4393 postgres: bgworker: logical replication launcher

Jun 06 14:00:39 pgdbadevbal800 systemd[1]: Starting PostgreSQL 10 database server...
Jun 06 14:00:39 pgdbadevbal800 postgres[4382]: 2019-06-06 14:00:39.692 EDT [4382] LOG:  listening on IPv4 address
"##.###.###.###",port 5432
 
Jun 06 14:00:39 pgdbadevbal800 postgres[4382]: 2019-06-06 14:00:39.696 EDT [4382] LOG:  listening on Unix socket
"/tmp/.s.PGSQL.5432"
Jun 06 14:00:39 pgdbadevbal800 postgres[4382]: 2019-06-06 14:00:39.704 EDT [4382] LOG:  redirecting log output to
loggingcollector process
 
Jun 06 14:00:39 pgdbadevbal800 postgres[4382]: 2019-06-06 14:00:39.704 EDT [4382] HINT:  Future log output will appear
indirectory "/hostname/pg/postgres/log".
 


It appears to fork successfully however the state still shows as "activating" and remains like that. We have another
boxin our environment, same OS but is running postgres 10.3-1PGDG.sles12 official package. The 10.7 in the example
aboveis from a tarball. Both hosts are using near identical systemd service files. The other box will start up and
reachan "Active (running)" state.
 

Other related information:
 - systemd version 228-150.29.1 (on both hosts)
 - os SUSE Linux Enterprise Server 12 SP3 (on both)
 - I do run a systemctl daemon-reload after any changes to service files.

Thank you again for reaching out!

-Kevin Kelly

-----Original Message-----
From: Francisco Olarte [mailto:folarte@peoplecall.com]
Sent: Thursday, June 06, 2019 1:44 PM
To: Kelly, Kevin <Kevin.Kelly@msx.bala.susq.com>
Cc: pgsql-general@postgresql.org; Lu, Dan <Dan.Lu@msx.bala.susq.com>
Subject: Re: Postgres 10.7 Systemd Startup Issue

On Thu, Jun 6, 2019 at 6:57 PM Kelly, Kevin <Kevin.Kelly@sig.com> wrote:
> We’re attempting to launch postgres via systemd and noticing that when invoking via systemctl start postgres.service
theprompt never returns. If we switch to another tty and check the status it shows as:
 
> Active: activating (start) since Thu 2019-06-06 09:36:32 EDT; 12min
> ago If we change the type from notify to forking we see the same behavior. The instance seems to be up and running
justfine, we just never see the active (running) status as we have come to expect.
 

Are you sure you have the postgres.service correctly configured? ( or you could post the ExecStart/Type config, or the
wholeservice file ).
 

The type tells systemd how to know the service has finished starting and is running, notify means it does systemd
integrationvia socket, with IIRC postgres does not. Forking means the usual server approach, server detachs and after
ExecStartreturns it is considered running.
 
Simple is for not detaching.

Your symptom seem to be caused by either using a execstart command which does not detach ( so forking waits forever for
initialisationto finish ) or for not having done daemon-reload to systemd ( so you are still in notify mode and it is
waitingforever for postgres to tell him it is ready ).
 

> We’re running on top of a stock SLES12 SP3. Could someone assist in tracking down why this service isn’t
transitioningto the active state?
 

Try posting some log, the service file ( to know which command you use ), maybe a ps trace, but I would go for checking
thetwo problems above first. My be t is on the second one ( and if it is that you'll have the surprise of it working
aftermachine reboot ).
 

Bear in mind many of us, althoguh wanting to help,  do not even know what "stock SLES12 SP3" is, so no idea on systemd
versionand/or service files content.
 

Francisco Olarte.

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended
recipient,please notify the sender immediately by reply and immediately delete this message and all its attachments.
Anyreview, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient
isstrictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer,
solicitationor recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her
employernor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the
informationcontained herein or that this message or any of its attachments is free of viruses.