RE: RHEL 7 (systemd) reboot - Mailing list pgsql-general

From Bryce Pepper
Subject RE: RHEL 7 (systemd) reboot
Date
Msg-id 21090661bc8a446680cb108fac2486f9@WNEXMBFEP03.KCSCP.CORP
Whole thread Raw
In response to Re: RHEL 7 (systemd) reboot  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: RHEL 7 (systemd) reboot  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
Adrian,

Thanks for being willing to dig into this.  

You are correct there are other scripts being called from mine (delivered by BMC with their software).   In order to
stayin support and work with their updates I use the vendor supplied scripts/programs.  
 

The Control-M product is installed on this single server and is broken down into the following parts:
Enterprise server with dedicated postgresql instance
Distributed datacenter with agent and dedicated postgresql instance
Linux datacenter with with agent and dedicated postgresql instance

To cut down on the noise, my post only focused on the "Distributed" side and shutdown process -- although the
ControlM_Shutdown.serviceunit stop script manages all of the above components.
 

In the ControlM_Shutdown.service there is a requires statement identifying that  network must be available while this
systemdunit runs.
 

You noticed that the eth0 disconnected in the /var/log/messages.   I showed that to highlight that the unit was not
executingin the order I had intended, again refer to the requires statement.
 

The second shebang is from one of the invoked subscripts (stop_ctmdist_server.sh) and is the "main" shutdown sequence
forthe Distributed datacenter (I think the "SQL server" echo from BMC is because it can be configured with other
databasesand they use it in a generic term --- not meaning sqlserver from Microsoft).
 

The dbversion check is being used to verify pgsql instance for this datacenter is running and returns a non-zero return
codeif the instance is unreachable (I could use pg_isready or pg_ctl but would diverge further from the BMC supported
technique).

You probably also noticed in the earlier posted shutdown service a requires of CTM_Postgre.service.  This was one of my
attemptsto ensure the instance was available by actually starting the instance outside of the BMC routines (if it is
alreadyrunning the BMC routines will not start -- the dbversion check is on the start side also).  I thought if I
managedthe postgresql instance outside of the product I could ensure it was running.  Unfortunately that didn't work as
theinstance shutdown on its own, presumably a resource (perhaps network) was terminated and postgresql shutdown.  
 

So to restate the original post...   It appears the postgresql instance is unavailable when the stop script runs.  

Thanks,
Bryce

[root@kccontrolmt01 ~]# systemctl --full cat ControlM_Shutdown.service
# /etc/systemd/system/ControlM_Shutdown.service
[Unit]
Description=Run ControlM shutdown process
Requires=graphical.target multi-user.target network.target network.service sockets.target
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target poweroff.target kexec.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/bin/bash /root/scripts/control-m_shutdown.sh
TimeoutStopSec=4min

[Install]
WantedBy=multi-user.target
[root@kccontrolmt01 ~]#


pgsql-general by date:

Previous
From: Mike Martin
Date:
Subject: Re: Advice on logging strategy
Next
From: Adrian Klaver
Date:
Subject: Re: RHEL 7 (systemd) reboot