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

From Adrian Klaver
Subject Re: RHEL 7 (systemd) reboot
Date
Msg-id 5c30d3c8-ddd0-452c-a667-cb1356c10c47@aklaver.com
Whole thread Raw
In response to RE: RHEL 7 (systemd) reboot  (Bryce Pepper <BPepper@KCSouthern.com>)
Responses RE: RHEL 7 (systemd) reboot  (Bryce Pepper <BPepper@KCSouthern.com>)
List pgsql-general
On 10/10/18 5:32 AM, Bryce Pepper wrote:
> Adrian,
> Thanks for the inquiry.  The function (db_execute_sql) is coming from a vendor (BMC) product called Control-M. It is
ascheduling product.
 
> The tmp file is deleted before I can see its contents but I believe it is trying to update some columns in the
CMS_SYSPRMtable.
 
> I also think the postgresql instance is already stopped and hence why the db_execute fails.  I will try to modify the
vendorfunction to save off the contents of the query.
 

Alright, I'm confused. In your earlier post you said the stop script is 
not running. Yet here it is, just not at the right time. I think a more 
detailed explanation is needed:

1) The stop script you are concerned about is a systemd  script, one 
that you created or system provided?

2) What is the shutdown service you refer to?

3) Is there a separate shutdown script for the Control-M product?

4) What do you expect to happen vs what is happening?

> 
> Bryce
> 
> p.s. Do you know of any verbose logging that could be turned on to catch when pgsql is being terminated?
> 
> 
> -----Original Message-----
> From: Adrian Klaver <adrian.klaver@aklaver.com>
> Sent: Tuesday, October 09, 2018 7:39 PM
> To: Bryce Pepper <BPepper@KCSouthern.com>; pgsql-general@lists.postgresql.org
> Subject: Re: RHEL 7 (systemd) reboot
> 
> This email originated from outside the company. Please use caution when opening attachments or clicking on links. If
yoususpect this to be a phishing attempt, please report via PhishAlarm.
 
> ________________________________
> 
> On 10/9/18 11:06 AM, Bryce Pepper wrote:
>> I am running three instances (under different users) on a RHEL 7
>> server to support a vendor product.
>>
>> In the defined services, the start & stop scripts work fine when
>> invoked with systemctl {start|stop} whatever.service  but we have
>> automated monthly patching which does a reboot.
>>
>> Looking in /var/log/messages and the stop scripts do not get invoked
>> on reboot, therefore I created a new shutdown service as described
>> here <https://unix.stackexchange.com/questions/211924/effect-of-reboot-signal-on-systemd-service-state>.
>>
>> It appears that PostGreSQL is receiving a signal from somewhere prior
>> to my script running.
>>
> 
>>
>> The database must be available for the product to shut down in a
>> consistent state.
>>
>> I am open to suggestions.
> 
> What is the below doing or coming from?:
> 
> db_execute_sql failed while processing
> /data00/ctmlinux/ctm_server/tmp/upd_CMS_SYSPRM_29448.
> 
>>
>> Thanks,
>>
>> Bryce
>>
>> *Bryce Pepper*
>>
>> Sr. Unix Applications Systems Engineer
>>
>> *The Kansas City Southern Railway Company *
>>
>> 114 West 11^th Street  |  Kansas City,  MO 64105
>>
>> Office:  816.983.1512
>>
>> Email: bpepper@kcsouthern.com <mailto:bpepper@kcsouthern.com>
>>
> 
> 
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Bryce Pepper
Date:
Subject: RE: RHEL 7 (systemd) reboot
Next
From: Adrian Klaver
Date:
Subject: Re: tds_fdw binary column