Re: systemd issues

From: Radoulov, Dimitre <>
Date: Thu, 2 May 2019 23:49:05 +0200
Message-ID: <>

Hi Michael,

yes, I get the same behavior when I don't use systemctl to stop/start the service. I'll let you know if I find how to deal with this scenario.

Anyway, I think that you could avoid the problem if you start the database using the systemctl command after the patching.


On 02/05/2019 19.40, Michael Schmitt wrote:
> Thanks,
> Yes, it is really the service definition that we are struggling with.
> We have found when we use type=forking , systemd will kill off our
> oracle processes during the next server shutdown instead of waiting
> for the database(s) to shutdown.† We are trying to avoid a db crash as
> part of a server shutdown.† It works fine if we do not bring down the
> database down between server boots.† This is even with killmode=none.†
> If you havenít run into that problem, we might need to test it again
> just incase the test got messed up for some other reason
> Thanks
> *From:* <>
> *On Behalf Of *Radoulov, Dimitre
> *Sent:* Thursday, May 02, 2019 2:52 AM
> *To:* Michael Schmitt <>;
> *Subject:* Re: systemd issues
> Hello,
> I wrote a simple script that seems to work, it starts/stops multiple
> Oracle instances and listeners (it looks for entries with Y in oratab).
> The content of the systemd service definition is reported in the header.
> You could try to use it as a template and adapt it for your environment.
> Dimitre
> On 01/05/2019 22.00, Michael Schmitt wrote:
> Hi Oracle-l
> Has anyone had any luck getting systemd to play nicely with Oracle
> databases?† It seems like every document I have read offers
> different suggestions and each of those come with their own set of
> issues
> The main issue we are having is systemd killing the oracle
> processes in different circumstances (when databases are manually
> restarted due to cold backups/patching/etc).† We really just want
> systemd to call our custom startup/shutdown scripts when the
> server reboots (and shutdown the database in advance of the
> network), instead of trying to manage the database processes
> Thanks in advance

Received on Thu May 02 2019 - 23:49:05 CEST

Original text of this message